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FOREWORD 


This  report  documents  the  results  of  analyses  performed  to 
extend  and  expand  the  definition  of  the  Automated  Tactical  Launch 
and  Recovery  System  (ATALARS)  presented  in  ESD-TR~86-259 ,  Advanced 
Air  Traffic  Control  Concept,  19  June  1986.  The  Electronic  Systems 
Division  (ESD)  Technical  Report  (TR)  concluded  that  tactical  air 
traffic  control  (ATC)  has  long  been  deficient  in  survivability  with 
no  firm  planning  to  resolve  future  needs.  It  formulated  a  concept 
that  eliminates  the  need  for  complex  ATC  systems  at  every  airbase, 
suggesting,  instead,  an  aircraft  based  system  with  a  single  ground 
control  unit,  integrated  to  provide  ATC  for  a  large  geographical 
area  including  multiple  launch  and  recovery  areas.  This  report 
further  develops  the  concept  by  presenting  the  results  of  a  detailed 
functional  analysis  and  a  preliminary  functional  design  effort.  It 
also  provides  recommendations  for  further  development  of  the  ATALARS 
concept.  - - 

The  study  effort  was  conducted  under  the  guidance  of  1st  Lt.  Guy 
C.  St.  Sauveur,  ESD/XRC.  Mr.  A.  Frueauf  of  ARINC  Research 
Corporation  was  th*  Project.  Leader  under  the  overall  management  of 
Mr.  P.  McCree,  the  TEMS  Manager  for  HH  Aerus^ace  Design  Co.,  Inc. 
Primary  contributors  to  the  report  were  Messrs,  A.  Frueauf  (ARINC 
Research  Corporation),  J.  McDermott  (ARINC  Research  Corporation),  D. 
Piligian  (ARINC  Research  Corporation),  R.  Hubbard  (ARINC  Research 
Corporation) ,  P.  Quinan  (Vanguard  Research,  Inc.),  and  K.  Creighan 
(HH  Aerospace  Design  Co.,  Inc.). 
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REPORT  SUMMARY 


The  Automated  Tactical  Aircraft  Launch  and  Recovery  System 
(ATALARS)  is  an  advanced  system,  in  the  conceptual  stage,  for 
performing  military  terminal  area  air  traffic  control  (ATC)  in  the 
post-2000  time  period.  The  ATALARS  will  provide  airspace 
management,  approach  control,  departure  control,  landing  guidance, 
and  other  ATC  facility  functions.  Rather  than  the  standard 
techniques  of  conventional  radar  surveillance,  voice  communications, 
and  centralized  ground  control,  the  ATALARS  will  use  new  techniques 
made  possible  by  near  term  technology.  Communications  wj.11  be  by 
both  data  link  (e.g.,  Joint  Tactical  Information  Distribution  System 
(JTIDS)  or  similar  systems)  and  voice  (e.g.,  HAUEl  QUICK  or  similar 
systems).  Surveillance  will  be  indirect  using  position  reporting 
from  the  aircraft  via  the  data  link  and  data  from  air  surveillance 
systems  also  using  data  link.  The  required  position  accuracy  will 
be  provided  by  new  navigation  systems  such  as  the  Global  Positioning 
System  (GPS).  Traffic  control  functions  will  be  split  between  the 
aircraft  (pilot  and  terminal)  and  ground  system  (controller 
supported  by  ADP  in  a  mobile  vehicle) . 

ATALARS  ground  units  will  be  capable  of  dispersed  deployment  and 
netting,  and  will  allow  multiple,  fixed-base,  off-base,  and  ad  hoc 
base  operations  with  other  tactical  air  operations  within  the 
tactical  theater  as  well  as  interoperability  with  Air  Force  and  Army 
air  defenses.  It  will  interface  with  Battle  Management  resources  to 
be  capable  of  overseeing  the  operation  and  area  conditions  to  a 
given  landing  area.  ATALARS  would  provide  essential  feedback  to 
pertinent  Battle  Management  elements  (i.e.,  Remote  Surveillance 
Units  and  Mobile  Control  Towers) .  ATALARS  must  perform  airspace 
management  (i.e.,  overall  management  of  the  traffic  in  its  assigned 
airspace),  approach  control  (i.e.,  controlling  the  traffic  intent  on 
landing  in  the  airspace),  and  airfield  traffic  management  (e.g., 
landing  guidance,  takeoff  scheduling)  to  the  extent  that  remaining 
airbase  facilities  cannot  do  so.  Each  of  these  three  functions 
involves  long  term  (next  operations  cycle)  planning,  short  term 
re-planning,  traffic  monitoring,  situation  monitoring  (e.g.,  runway 
status,  weather),  and  control  (e.g.,  issuing  instructions).  These 
functions  have  been  decomposed  using  the  techniques  of  structured 
analysis  and  are  described  in  Section  6.0. 

These  three  basic  Functions  have  many  elements  in  common  (e.g., 
aircraft  tracking,  weather  monitoring).  Combining  these  common 
elements  leads  to  the  definition  of  system  functions  (e.g.,  a 
surveillance  function).  The  system  functions  have,  in  turn  been 
decomposed  and  allocated  to  subsystems  (e.g.,  the  elements  of  the 
surveillance  function  were  allocated  between  the  aircraft  and  the 
van).  Section  7.0  provides  a  preliminary  overview  of  system  design 
concepts  and  their  allocation  to  subsystems.  For  the  analysis, 
ATALARS  was  defined  as  consisting  of  four  subsystems: 
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I 


1.  The  van  subsystem  which  consists  of: 

a.  Uehicle(s)  and  associated  support  equipment  (power, 
heating,  venitilation ,  air  conditioning,  etc.) 

b.  ADP  subsystem 

c.  Communications  subsystem 

2.  The  aircraft  subsystem  which  consists  of: 

a.  a  modified  communications  unit 

b.  interfaces  between  the  communications  units  and  other 
aircraft  subsystems  (e.g.,  navigation) 

3.  The  airbase  subsystem  which  would  include: 

a.  a  runway  monitoring  subsystem 

b.  a  communications  subsystem  for  interfacing  with  the 
ATALARS  van  (ADP  subsystem) 

The  external  interface  subsystem  which  would  include  any 
ATALARS  unique  communications  hardware/sof tware  for 
interfacing  with  external  agencies  such  as  tactical  command 
and  control  facilities. 

The  functions  to  be  allocated  to  these  subsystems  are  defined  as: 

1.  Surveillance  which  includes  establishing  and  maintaining 
tracks  as  well  as  obtaining  and  maintaining  data  relevant  to 
the  track. 

2.  Situation  monitoring  and  assessment  which  includes 
identification  of  generally  adverse  ATC  situations  and 
issuance  of  appropriate  advisories  to  pilots/controllers . 

3.  Control  of  air  traffic  which  aggregates  various  control  and 
control  related  functions  (handoffs,  stack  extraction, 
spacing,  sequencing). 

4.  Control  of  ground  traffic  which  exercises  control  over  ground 
traffic  (aircraft  and  ground  vehicles)  at  an  airfield. 

5.  Landing  control  which  includes  landing  scheduling  and 
provides  guidance  to  aircraft  approaching  a  landing  gate. 

6.  Departure  control  which  schedules  aircraft  departures  and 
provides  the  final  approval  prior  to  takeoff. 

7.  Planning  which  includes  overall  planning  and  plan  adjustment 
of  airspace  management,  route  selection,  and  scheduling. 

8.  Exercise/training  which  includes  support  ^or  data  collection 
and  simulation. 
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The  actual  design  is  driven  by  numeric  requirements  (e.g.,  the 
number  of  aircraft  simultaneously  in  the  assigned  airspace), 
operational  considercitdons  (e.g.,  pilot  workload),  environmental 
considerations  (e.g.,  variance  in  aircraft  avionics  suites),  near 
term  technology  (e.g.,  Jl'IDS,  GPS),  and  other  factors.  Section  8.0 
provides  a  preliminary  identification  of  these  factors  and  assesses 
their  potential  impact  on  design. 

Section  9.0  provides  planning  information  for  the  continuation 
of  the  program,  ft  preliminary  schedule  is  provided  for  follow-on 
program  tasks.  Appendix  C  contains  an  initial  cost  estimate  of  the 
program  tasks  through  the  completion  of  a  feasibility  demonstration 
of  the  ATALARS  concept. 

This  study  effort  concludes  that  several  analyses  must  be 
performed  lO  investigate  critical  design  areas  to  minimize  the  risk 
for  a  full  scale  development  program. 


SECTION  1.0 
INTRODUCTION 


This  document  contains  the  results  of  a  US  Air  Force  contracted 
study  effort  on  the  Automated  Tactical  Aircraft  Launch  and  Recovery 
System  (ATALARS)  concept  which  was  formulated  in  ESD- TR- 86-259 , 
Advanced  Air  Traffic  Control  Concept,  19  June  1986.  The  ATALARS  is 
an  advanced  system  for  performing  tactical  military  terminal  area 
air  traffic  control  (ATC)  in  the  post-2000  time  peri  -■* .  The  study 
was  conducted  under  the  guidance  of  1st  Lt.  Guy  C.  St.  Sauveur, 
ESD/XRC . 

1.1  BACKGROUND 

Since  1979  the  Air  Force  Systems  Command  Uanguard  process  has 
identified  through  extensive  analysis  of  the  ATC  mission  area  a  lack 
of  long  range  concept  developments  to  address  projected  mission 
requirements  of  the  1990's.  Numerous  programs  have  evolved  which 
enhance  or  replace  current  equipment  being  used  in  ATC. 
Unfortunately,  these  programs  are  not  survivability  oriented  based 
on  the  projected  threat  and  sortie  requirements .  Survivability 
studies  were  performed  between  1982-1986  under  sponsorship  of  ESD, 
Hanscom  AFB.  These  studies  identified  major  issues  relating  to  ATC 
in  a  tactical  war'  me  environment  and  edified  the  need  for  long 
range  planning  with  survivability  as  the  major  thrust.  The  ATALARS 
concept  as  presented  in  F.SD-TR-86-259  evolved  out  of  these  efforts. 

1.2  SCOPE 

This  report  builds  upon  the  concept  presented  in  the  ESD 
technical  report  by  performing  a  functional  analysis  of  terminal  ATC 
services.  The  resulting  functional  design  is  integrated  into  the 
expected  tactical  environment  of  the  post-2000  time  period. 

1.3  CONTENT 

The  report  is  composed  of  10  sections  with  four  supporting 
appendices.  Section  2.0  describes  the  ATC  mission  requirements . 
Section  3.0  descirbes  ATC  user  capabilities.  Section  4.0  identifies 
ATC  deficiencies.  Section  B.O  provides  the  ATALARS  concept  of 
operations.  Section  6.0  identifies  and  provides  an  analysis  of 
ATALARS  mission  functions.  Section  7.0  combines  the  ATALARS 
functions  into  subsystems.  Section  8.0  discusses  the  design 
considerations  for  ATALARS.  Section  9.0  provides  program  and 
feasibility  demonstration  planning  information  for  validating  the 
ATALARS  concept.  Section  10.0  provides  conclusions  and 
recommendations  of  the  study  effort. 


SECTION  2.0 
MISSION  REQUIREMENTS 


Although  the  concept  for  performing  military  terminal  area  ATC 
(Figure  2-1)  in  the  post-2000  time  period  is  anticipated  to  change, 
the  aircraft  missions  (e.g.  reconnaissance,  refueling,  interdiction) 
will  remain  essentially  the  same.  However,  enhanced  aircraft 
performance  and  advanced  avionics  will  provide  for  more  flexible 
mission  profiles  and  inflight  rerouting.  The  number  and  variety  of 
aircraft  performing  the  missions  will  increase.  It  is  expected  that 
more  flexible,  ad  hoc,  dispersed  aircraft  basing  will  be  used. 

Larger  numbers  of  smaller  buses  and  covert  off-base  locations  will 
exist.  Tactical  operations  will  be  changed  to  include  new 
procedures  for  entry  into  base  airspace,  altitude  of  approach,  and 
holding  patterns.  ATC  operations  will  interface  with  air  defense 
weapon  systems  and  will  have  to  take  place  despite  increased  wartime 
threats  that  will  include  significant  monitoring,  jamming,  radiation 
homing,  and  destruction  capabilities  by  the  enemy. 

2.  1  AIRCRAFT  TYPES 

The  types  of  aircraft  requiring  ATC  services  in  this  time  period 
will  consist  of  a  wider  mix  than  in  the  1980-1995  time  period.  This 
mix  will  consist  of  versions  of  the  present  fleet,  with  new 
avionics,  extended  life  versions  of  the  present  fleet  and  advanced 
aircraft  now  on  the  drawing  board.  Extended  life  versions  of  the 
circa  1986  aircraft  will  exhibit  characteristics  different  from 
today's  versions,  including  shorter  and  faster  landing  and  takeoff 
capabilities.  They  will  also  have  improved  cockpit  suites  that  will 
display  extensive  situation  data  from  on-board  sensors  and  data 
received  via  tactical  data  links. 

2.1.1  Advanced  Aircraft 

The  more  advanced  aircraft  will  have  operating  profiles  allowing 
shorter  landings  and  takeoffs.  These  aircraft  will  be  highly 
maneuverable  and  have  a  variety  of  landing  and  takeoff  profiles. 
Aircraft  will  also  be  able  to  operate  on  unprepared  terrain  at 
off-base  landing  sites.  Stealth  techniques  will  be  used  on  some 
aircraft  to  deny  enemy  radar,  consequently  denying  friendly  radar 
detection  as  well. 

2.1.2  Transport  and  Bomber 

Transport  and  bomber  aircraft  with  precise  landing  entry  windows 
and  minimum  holding  time  will  require  ATC  services.  Preplanned 
coordination  and  real-time  inflight  rerouting  will  be  necessary  to 
optimize  traffic  control  of  these  types  of  aircraft  and  to 
interweave  them  with  conventional  aircraft  at  dynamic  landing 
locations . 


tow  In  PmI-2000  ATC 


2.1.3 


Helicopters 


fin  extensive  number  of  helicopters  and  hover  aircraft  twill  be  in 
the  inventory.  Aircraft  from  the  Army,  Navy,  and  Marine  Corps  twill 
interact  in  the  airspace.  The  aircraft  and  procedures  of  these 
services  must  be  accommodated,  as  well  as  those  of  NATO  and  other 
allies  . 

2.2  OTHER  CONSIDERATIONS 

ATC  operations  in  the  post- 2000  time  frame  twill  also  be 
influenced  by  other  factors,  some  of  which  are  addressed  in  the 
following  paragraphs. 

2-2.1  Basing  Concepts 

The  basing  concepts  in  this  time  period  will  be  driven  by  the 
need  for  survivability  and  recovery  from  battle  damage.  As  the 
range  and  accuracy  of  tactical  weapons  increase,  airbases  will 
become  more  vulnerable  to  attack  and  will  result  in  the  use  of 
non-fixed  base  configurations.  It  is  expected  that  the  aircraft 
types  will  allow  smaller  geographic  space  for  airbases.  The  fixed 
bases  will  also  contain  alternate  strip  areas,  either  contingent  to 
the  base  or  nearby.  Some  clustering  of  runways  in  a  geographic  area 
will  be  provided,  but  they  will  be  dispersed  from  each  other  to 
prevent  collateral  destruction.  Also,  dispersed  covert  small 
landing  fields  will  be  used.  Dispersed  bases  will  have  minimum 
resources  and,  to  the  degree  possible,  be  kept  covert  until 
necessary  for  use.  The  runways  will  be  narrower  and  shorter.  The 
physical  makeup  of  these  bases  will  vary  greatly  from  constructed 
bases  to  ad  hoc  field  arrangements  using  dirt  strips  and  roadways. 
Clustered  and  dispersed  runways  will  result  in  overlapping  areas  of 
approach  and  departure  paths.  Multiple  runways  will  have  to  be 
controlled  by  a  single  control  facility.  Bases  will  likely  change 
rapidly  relative  to  availability  and  supportability  for  the  aircraft 
requiring  ATC  service. 

2.2.2  Operational  Concepts 

In  the  post-2000  time  period,  terminal  ATC  operations  will  be 
required  to  be  more  flexible  and  real-time  managed  than  at  present. 
Preplanned  information  will  be  available,  but  will  change  to  match 
the  operational  situation.  Aircraft  navigation  systems  will  permit 
more  flexible  routes  to  and  from  airbases,  not  following  fixed 
structures  and  entry  points.  In  addition,  because  of  the  ad  hoc 
bases,  extensive  publication  of  operation  procedures  will  not  be 
available  for  prestudy  by  aircraft  commanders.  Predefined,  specific 
landing  procedures  will  not  always  be  possible.  The  ad  hoc  nature 
of  the  bases  will  require  that  greater  real-time  flight  .information 
be  conveyed  to  aircraft  on  base  locations  and  configurations. 

Control  operations  will  have  to  direct  aircraft  to  appropriate  bases 
within  an  overall  area,  perhaps  to  covert  bases  or  areas  previously 
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not  used  for  landings.  Takeoff  flow  control  and  location  of  holding 
positions  will  be  dynamic  to  account  for  base  battle  damage  and  the 
need  to  be  unpredictable. 

The  operational  situation  will  require  higher  sortie  rates. 

This  will  be  reflected  in  aircraft  flying  closer  together  ^  and 
from  areas  smal"  r  than  the  current  situation. 

2.2.3  Environmental  Conditions 


The  environment  in  which  ATC  will  have  to  opereite  will  be 
significantly  hostile.  Landings  and  takeoffs  must  be  possible  in 
all  weather  and  light  conditions.  Blind  landings  must  be  possible 
in  this  time  period  for  all  high  priority  aircraft,  if  not  ail 
aircraf t . 


Enemy  countermeasures  will  be  present.  These  will  be  both 
direct  and  collateral  attacks  by  the  enemy  that  will  require 
maintenance  of  ATC  in  the  presence  of  electronic  countermeasures, 
electromagnetic  pulse,  anti -radiation  missile,  and  chemical  threats. 

The  ATC  services  must  have  a  method  of  self-healing  and 
restoral,  including  the  ability  to  rapidly  reconstitute  itself.  The 
ATC  function  must  be  expandable  to  take  over  different  geographic 
areas  in  addition  to  its  originally  designated  area. 

2.3  TERMINAL  ATC  SERVICES 


In  the  post-2000  time  period,  it  is  expected  that  the  terminal 
ATC  services  will  have  to  be  similar  to  those  services  provided 
today,  but  with  expanded  capability  and  flexibility.  The  services 
provided  will  include  area  airspace  management,  approach  control, 
landing  control,  departure  control,  information  advisories,  and 
interoperation  of  ATC  with  other  tactical  mission  areas  (Figure  2-2). 


2.3.1  Area  Airspace  Management  Service 


The  area  airspace  management  service  should  ens 
operation  and  passage  within  an  area  airspace,  whi.1 
various  aircraft  to  carry  out  their  assigned  missio 
service  should  execute  control  over  all  aircraft  in 
maintaining  their  safe  separation  and  routing.  It 
the  surveillance  of  all  friendly  aircraft  in  the  ai 
the  position,  identity,  and  plans  of  all  aircraft, 
should  order  the  movement  of  the  aircraft  to  their 
destination  by  efficient  and  safe  operations.  The 
managed  should  extend  from  an  individual  base  up  to 
containing  multiple  bases  and  different  base  types, 
for  managing  a  hundred  or  more  aircraft  simultaneoi 
provided . 
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2.3.2  Approach  Control  Service 


Approach  control  service  should  be  provided  for  aircraft  wishing 
to  land  or  approach  an  area  within  the  airspace  being  managed.  This 
service  should  efficiently  and  safely  bring  an  aircraft  into  the 
area  covered  by  the  precision  approach  service  and  visual  landing 
point.  The  approach  control  service  should  be  provided  for  up  to  10 
bases  and  up  to  300  aircraft  operations,  recognize  emergency  landing 
needs,  and  respond  to  aircraft  requiring  this  special  service  by 
efficient  insertion  into  the  landing  operations.  It  should 
dynamically  move  and  automatically  adjust  the  flight  parameters  of 
stacked  aircraft  without  forcing  all  aircraft  to  change  their 
approach  plans  and  timing. 


2.3.3  Landing  Control  Service 

Landing  control  service  should  be  provided  under  all  operational 
conditions:  day,  night,  adverse  weather,  and  damaged  runways.  The 
landing  service  should  permit  blind  landing  operations  and  allow 
flexible  approaches,  optimum  for  the  aircraft  and  operational 
conditions  involved.  The  service  should  be  integrated  between  the 
pilot  and  the  ground  control  function.  This  integration  would  allow 
for  real-time  exchange  of  essential  information.  The  landing 
service  should  also  provide  control  instructions  and  guidance  for 
missed  approaches  and  redirection  to  an  efficient  reentry  into  the 
landing  sequence. 

The  service  should  be  capable  of  simultaneous  operation  with 
close  proximity  airfields  while  limiting  the  length  of  time  where 
structured  and  fixed  flight  paths  are  required  to  be  flown.  The 
service  should  not  limit  the  number  of  aircraft  that  can  obtain 
guidance  at  any  one  time. 

The  landing  control  service  should  be  capable  of  keeping  track 
of  runway  status  and  determining  the  appropriate  runways  to  use  for 
landing  operations.  This  should  include  knowledge  of  support 
facilities  and  the  landing  site's  traffic  load,  both  present  and 
predicted . 


2.3.4  Departure  Control  Service 

The  departure  control  service  should  provide  efficient  spacing 
and  control  of  takeoff  operations,  responses  to  requests  for 
takeoff,  and  sequencing  of  takeoffs  to  effectively  use  the  runway 
between  landings  and  takeoffs.  The  service  should  provide  for  the 
management  of  takeoffs  to  efficiently  reduce  ground  delay  time  and 
exposure  to  attack.  It  should  provide  flow  control  that  will  insert 
the  aircraft  into  the  airspace  in  a  safe  manner,  timed  for  efficient 
execution  of  its  mission.  This  service  should  also  minimize  Lhe 
adjustments  to  the  desired  aircraft  optimum  flight  geometry  and  to 
the  flight  paths  of  other  coexistent  aircraft.  Departure  control 
services  should  be  able  to  maintain  cognizance  over  all  aircraft  and 


their  status  at  multiple  bases.  It  should  provide  sufficient 
planning  capability  to  preassign  takeoff  slots  and  make  dynamic 
adjustments. 

2.3.5  Information  Advisories  Service 

This  service  should  provide  in-flight:  advisory  information. 
Aeronautical  information  pertinent  to  aircraft  operation  should  be 
provided  to  support  landing  and  takeoff  operations.  Currently, 
automatic  terminal  information  service  provides  this  essential 
information.  The  proposed  system  would  incorporate  additional 
battle  management  information  such  as  runway  status,  enroute  weather 
conditions,  expeditious  routing,  potential  hazards,  and  defense 
elements.  It  should  provide  emergency  assistance  to  lost  aircraft 
or  those  in  distress. 

2 . 3 . 6  Tactical  System  Interoperability  Service 

Interoperability  of  the  ATC  operations  with  tactical  defensive 
and  offensive  air  operations  in,  and  adjacent  to,  the  controlled 
airspace  should  be  provided.  The  ATC  and  tactical  operations  should 
be  integrated  through  the  netting  of  sensors  and  control  elements. 

The  ATC  control  units  should  be  a  part  of  the  tactical  network  to 
exchange  information.  The  ATC  operations  should  be  capable  of 
receiving  track  information  from  the  tactical  surveillance  network. 

It  should  provide  aircraft  flight  plans  and  aircraft  identification 
to  the  tactical  elements  via  the  tactical  track  distribution  network. 

To  provide  safe  passage  of  aircraft,  direct  interoperation  with 
base  air  defense  elements  should  be  provided.  The  ATC  service 
should  supply  the  air  defense  elements  with  position  data  on 
approaching  aircraft,  as  well  as  providing  information  on  dynamic 
base  approach  and  takeoff  corridors . 


SECTION  3.0 
USER  CAPABILITIES 


The  ATC  operations  of  the  late  1980s  to  early  1990s  will  be  up¬ 
graded  through  programs  now  planned.  This  upgr.  ^ng  includes  new 
facilities  being  deployed  into  the  field  through  the  1990s.  The 
systems/facilities  described  in  the  following  paragraphs  are 
expected  to  be  in  place  in  the  pre-2000  time  period. 

3.1  MOBILE  MICROWAVE  LANDING  SYSTEM  (MMLS) 

The  Mobile  Microwave  Landing  System,  like  the  fixed  base  MLS,  is 
a  precision  approach  and  landing  guidance  system  providing  a  landing 
capability  for  operations  in  adverse  weather.  The  MMLS  consists  of 
ground-based  precision  approach  equipment  that  generates  microwave 
guidance  signals,  thereby  enabling  MLS~equipped  aircraft  to 
continuously  display  aircraft  position  relative  to  a  pilot-selected 
course  and  glidepath  down  to  a  minimum  decision  height.  The  system 
includes  azimuth  antenna,  elevation  antenna,  and  precision  distance 
measuring  equipment.  A  variety  of  tactical  missions  can  be 
satisfied  by  the  MMLS  such  as  an  initial  precision  approach  and 
landing  capability  to  a  small,  hastily  established  assault  zone, 
restoral  at  bases  that  have  lost  their  precision  approach  control, 
and  a  landing  capability  at  newly  established  airfields. 

3.2  MEW  MCljlLE  RADAR  APPROACH  CONTROL  (RAPCON) 

The  New  Mobile  RAPCON  (NMR)  will  provide  a  rapidly  deployable, 
wartime,  ATC  RAPCON  for  restoring  terminal  area  ATC  services  at 
fixed  bases  and  establishing  RAPCON  operations  at  alternate  and  bare 
base  airfields.  The  operations  subsystem,  the  radar  subsystem,  and 
the  support  equipment  that  comprises  the  NMR  will  be  used  for 
forward  area  tactical  operations  in  a  hostile  environment.  During 
wartime,  NMR  operations  will  support  tactical  wing  and  squadron 
lev^l  high  surge,  sortie  generation  capabilities.  The  highly  mobile 
operations  subsystem  orovicies  a  radar  approach  facility  that  houses 
four  terminal  ATC  positions  and  associated  communication.  The 
operations  subsystem  together  with  the  radar  subsystem  provides 
RAPCON  and  area  control  services,  primary  and  secondary  surveillance 
radar  landing  service,  and  alerts/advisories  to  maintain  flight 
safety . 

3.3  TOWER  RESTORAL  VEHICLE  (TRV) 

The  Tower  Restoral  Vehicle  will  provide  Air  force  ATC  units,  at 
designated  tactical  airbases,  the  capability  to  rapidly  restore 
control  tower  assets.  The  TRV  is  an  austere,  fully  self-contained, 
ATC  control  tower  facility  with  a  limited  mission  duration  of  up  to 
7  days,  that  is  intended  to  support  the  survivability  of  ATC 
operations  under  wartime  conditions.  The  system  includes 
ground-to-air  and  intrabase  radio  communications ,  a  small 


shelterized  lower  mounted  on  a  standard  1-3/4  ton  military  off-road 
vehicle,  and  a  towed  trailer.  The  highly  mobile,  self-propelled  1  RU 
will  be  capable  of  supporting  limited  surge  launch  recovery 
operations  under  visual  meteorological  conditions.  •  n 

conjunction  with  other  assets,  it  will  also  support  k>  pe>  Mions 
under  instrument  flight  rules. 

3.4  SURUEILLANCE  RESTORAL  UEHICLE  (SRU) 

The  Surveillance  Restoral  Uehicle  will  provide  Air  Force  ATC 
units  with  a  minimal  surveillance  and  approach  contro1  capability  in 
the  event  of  loss  of  fixed  surveillance  and  radar  approach  control 
assets,  or  support  to  off  base  and  alternate  landing  strips.  The 
system  is  housed  in  a  highly  mobile,  self-propelled  vehicle  capable 
of  a  mission  length  up  to  7  days.  It  includes  a  tactical  secondary 
surveillance  radar  capability,  ground-to-air  and  intrabase  voice 
communications,  a  small  operations  shelter  mounted  on  a  standard 
1—1/4  ton  military  off-road  vehicle,  and  a  towed  trailer.  The  SRU 
will  be  capable  of  supporting  limited  surge  launch  and  recovery 
operations  under  visual  meteorological  conditions  and  instrument 
meteorological  conditions. 

3.5  HAUE  QUICK  RADIO 

The  HAUE  QUICK  Program  provides  an  air/air  and  air/ground  jam 
resistant  modification  to  selected  airborne  and  ground-based 
radios.  The  design  utilizes  a  frequency  hopping  capability, 

Channel  or  frequency  changes  are  made  many  times  a  second  in  an 
apparently  random  manner  so  that  no  pattern  is  evident  to  a 
potential  hostile  jammer.  The  scheme  is  implemented  by  storing 
within  every  HAUE  QUICK  Radio  a  patte,  ,i  of  frequencies  to  be  used 
for  a  given  day  and  utilizing  this  pattern  according  to  the  time  of 
day.  HAUE  QUICK  radios  retain  the  capability  to  operate  in  a  normal 
(non-hopping)  mode. 

3.6  JOINT  TACTICAL  INFORMATION  DISTRIBUTION  SYSTEM  (JTIDS) 

The  JTIDS  is  an  advanced  radio  system  which  provides  information 
distribution,  position  location,  and  identification  capabilities  in 
an  integrated  form  for  application  to  tactical  military  operations. 
The  JTIDS  architecture ,  signal  and  message  structures  provide  a 
building  block  for  a  wide  variety  of  information  distribution 
techniques  that  can  be  configured  by  the  user  to  match  his 
particular  needs.  Information  distribution  is  accomplished  by  the 
pooling  of  time  slots  into  participation  groups  and  the  assignment 
of  the  various  net  management  time  slot  access  modes  and  relay  modes 
of  the  group.  The  JTIDS  distributes  information  at  high  rates, 
encrypted  in  such  a  way  as  to  provide  security  and  with  sufficient 
jam  resistance  to  yield  high  reliability  in  a.  hostile 
electromagnetic  environment.  The  system  provides  a  capability  to 
interconnect  scattered  sources  and  users  of  information.  It 
provides  surface  and  airborne  elements  with  both  a  position  location 
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capability  within  a  common  position  reference  grid  and  an  intrinsic 
identification  capability  through  the  dissemination  of  secure 
position  and  identity  information.  The  0T1DS  also  provides  a 
capability  for  the  transfer  of  digitized  voice  data. 

3.7  PHYSICAL  SURUIUABILITY  FACILITIES 

Several  efforts  have  been  initiated,  some  of  which  have  boon 
discussed  in  the  preceding  paragraphs,  to  improve  ATC  performance 
under  various  wartime  threats.  Survivability  of  ATC  systems  in  a 
wartime  environment  is  essential.  The  Air  Force  is  identifying  a 
set  of  assets  that  can  be  rapidly  deployed  to  provide  Quick  Wartime 
Restoral  of  TRACALS  Equipment  and  Services  (QWROl'ES)  .  Current 
QWROTES  concepts  envision  that  these  assets  will  be  stored 
in-theater  within  semi-hardened  facilities  that  are  remote  from 
potential  on-base  targets .  Plans  are  also  in  being  to  semi-harden 
fixed  base  RAPCON  facilities. 


SECTION  4.0 
DEFICIENCY  ANALYSIS 


Although  the  programs  described  in  Section  3.0  will  improve  the 
ATC  capabilities,  residual  deficiencies  will  still  exist.  The  enemy 
threat  will  also  have  evolved,  overcoming  some  of  the  defensive 
mechanisms  provided  by  these  systems,  and  leaving  the  ATC  operations 
with  the  following  shortfalls. 

4.1  UULNERAB1LITY 

The  ATC  operations  will  be  dependent  on  active  sensor  radiation 
for  surveillance  of  aircraft  that  can  be  exploited  by  the  enemy. 
These  radiations  can  pinpoint  tho  location  of  runways  and 
concentration  points  of  aircraft.  Physical  vulnerability  remains  a 
key  issue.  General  location  of  the  ATC  systems  close  to  runways 
will  continue  to  subject  them  to  collateral  damage  when  a  base  is 
attacked.  This  could  include  possible  direct  attack  against  ATC 
facilities  during  periods  of  increased  sortie  activity. 

4.2  COUERAGE  AND  CAPACITY 

Capacity  limits  of  existing  and  planned  systems  will  be  exceeded 
because  major  activities  remain  manual  and  the  number  of  aircraft  to 
be  controlled  exceed  design  capacities.  Multiple  base  netting 
proposals  will  not  diminish  the  overload  factor  for  control.  The 
required  recovery  rates  of  70-100  aircraft  per  hour,  will  not  be 
supported . 

4.3  ELECTRONIC  COUNTERMEASURES 

An  electronic  countermeasures  shortfall  will  remain,  even  with 
the  improved  voice  communications  provided  by  HAUE  QUICK  radios. 
Deficiencies  will  exist  because  of  changing  threat  situations  that 
may  overcome  the  protection  provided  by  these  radios. 

The  surveillance  portion  of  the  ATC  operations  remains 
vulnerable  because  of  the  use  of  active  radar  sensors  that  will  be 
jarnmable.  The  secondary  radar  (beacon)  subsystem  remains  vulnerable 
to  collateral  jamming. 

4.4  SECURITY 

The  planned  implementations  will  not  offset  the  threat  of  enemy 
monitoring.  The  sys  l  orris  do  not  appreciably  increase  the  degree  of 
security  provided  to  the  information  transfer  required  for  ATC 
operation . 

4.5  RESTORATION 

The  planned  ATC  configuration  will  remain  somewhat  short  of  the 
required  restoral  setup  times.  Sufficient  A IX  units  will  not  be 
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provided  in  the  inventory  to  permit  all  bases/runways  to  be 
individually  equipped  with  restoration  equipment.  Flexibility  to 
rapidly  move  to  new  locations  with  mobile  assets  will  not  be 
adequate . 

4.6  INTEROPERABILITY 

Increased  interoperability  with  other  tactical  systems  will 
remain  at  a  low,  slow  level  and  will  be  carried  out  primarily  by 
voice.  Interfaces  with  local  air  defense  missile  units  will  remain 
somewhat  disconnected  and,  if  available,  carried  out  by  voice 
without  an  adequate  common  grid  reference  between  systems. 

DoD  efforts  will  continue  to  achieve  interoperability  of  future 
tactical  systems  through  standard  data  interfaces  and  information 
exchange  formats.  Modifications  to  some  systems  may  be  required  to 
meet,  this  standard,  or  a  special  interface  maybe  provided  to 
accommodate  other  formats  which  are  widely  used  by  tactical  systems. 

4.7  ACCURACY  AND  RESPONSIVENESS 

Inadequate  accuracy  and  responsiveness  will  continue  to  exist. 
Radar  type  accuracies  will  be  inadequate  for  high  speed  maneuverable 
aircraft  in  this  time  period.  The  ability  to  reduce  aircraft 
separation  to  increase  sortie  rates  is  directly  dependent  upon  the 
accuracies  and  timelines  of  the  information  used  for  ordering  the 
aircraft  into  landing  and  takeoff  queues.  The  planned  systems  will 
remain  dependent  upon  radar  operations  that  will  be  corrupted  and 
disabled  by  jamming,  local  clutter,  and  terrain  masking. 
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SECTION  5.0 
CONCEPT  OE  OPERATIONS 


The  ATALARS  concept  is  to  provide,  in  a  tactical  environment, 
integrated  airspace  management,  approach  control,  departure  control, 
and  landing  functions  in  the  post-2000  time  period.  It  is  currently 
not  intended  as  a  replacement  for  existing/planned  facilities  and 
systems,  but  rather  as  a  survivable  supplement  which  can  take  over 
ATC  related  functions  as  it  becomes  necessary  because  of  degradation 
due  to  enemy  action  or  other  factors.  Thus,  ATALARS  must  be 
flexible  in  terms  of  increasing  or  decreasing  the  number  and  types 
of  functions  it  must  perform.  It  must  be  integrated  physically  and 
functionally  into  the  overall  airspace  management  system,  given  the 
physical  and  functional  configuration  of  that  system  at  any  given 
point  in  time. 

The  typical  European  conventional  war  scenario  provides  a 
context  for  visualizing  the  role  of  ATALARS.  At  the  start  of  the 
war,  the  existing  airspace  management  system  (Army  Airspace  Command 
and  Control,  Air  Force  Tactical  Air  Control  System  (TACS),  ATC 
facilities  at  the  airbases)  provides  all  of  the  necessary 
capability.  It  is  expected  that  the  airfields,  being  fixed 
facilities,  will  be  subject  to  conventional  air  attack  as  well  as 
sabotage  and  unconventional  attacks.-  Assuming  a  degree  of  enemy 
success,  airfields  and  associated  control  facilities  will  be  in 
various  states  of  servicability .  Contingency  plans  for  using 
alternate  fields  and  even  highways,  such  as  autobahns  in  West 
Germany,  will  be  implemented. 

These  alternates  will  also  have  varying  degrees  of  control 
capability.  In  addition,  damaged  airfields  and  alternates  will  have 
different  servicing  capabilities/rates,  forcing  replanning  of 
airfield  utilization.  The  situation  will  be  extremely  dynamic  due 
to  repair  activities,  continuing  enemy  attacks  and  changing  mission 
requirements . 

An  ATALARS  integrated  into  this  environment  can  be  viewed  as  an 
air  traffic  control  element  servicing  one  or  more  distributed 
airfields  (i.e.  where  an  ATC  element  normally  services  one  airfield 
with  multiple,  essentially  collocated  runways  and  facilities, 

ATALARS  services  one  or  more  "airfields"  with  geographically 
separated  runways  and  facilities). 

Due  to  the  geographic  dispersion,  ATALARS  may  have  to  deal  with 
a  larger  volume  of  airspace  than  normally  attributed  to  ATC  airbase 
facilities.  In  geographically  constrained  areas  (e.g.,  the  "Iron 
Triangle"  in  West  Germany),  this  may  result  in  aircraft  operating  in 
the  ATALARS  airspace  over  which  an  ATC  airbase  facility  would  not 
normally  exercise  control.  At  a  minimum,  ATALARS  must  maintain  an 
awareness  of  these  aircraft  and  potentially  provide  guidance  for 
flight  safety  purposes. 
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ATALARS  would  provide  the  minimum  necessary  control  to  maintain 
operations  in  this  environment.  Similar  situations  can  be 
constructed  for  a  Korean  war.  Middle  Eastern  war  or  Caribbean 
conflict  where  the  introduction  of  substantial  air  forces  could 
temporarily  exceed  the  capability  of  the  host  country  and  U.S. 
introduced  airspace  management  systems. 

The  ATALARS  would  be  deployed  and  operateu  at  the  direction  oF 
the  HQ  Tactical  Air  Forces  (HQ1AF)  or  Tactical  Air  Control  Center 
(TACC)  or  analogues  such  as  NATO  (e.g.,  HQ  Allied  Air  Forces  Central 
Europe  (AAFCE)  or  the.  HQ  of  an  Allied  Tactical  Air  Force  (ATAF))  in 
the  various  theaters.  The  airspace  and  control  responsibilities 
within  that  airspace  would  be  defined  and  assigned  to  ATALARS  as 
part  of  the  normal  planning  process  for  each  operations  cycle. 
Adjustments  would  be  made  as  required . 

Given  its  assignment,  ATALARS  would  establish  interfaces  and 
coordinate  interface  procedures  with  control,  systems  responsible  for 
abutting  airspace,  air  defense  entities  operating  within  the  ATALARS 
airspace,  and  command  and  control  facilities,  if  any,  at  the 
airfields/airbases  in  the  ATALARS  airspace.  These  interfaces  would 
provide  for  exchange  of  tracking  and  identification  data,  handoff  to 
other  control  systems,  and  notifications  of  (impending)  activity. 

The  expected  activity  within  this  airspace  would  be  provided  to 
ATALARS  via  normally  developed  Air  Task  Orders  (ATOs)  and  flight 
plans  as  well  as  adjustments  thereto.  Constraints  on  that  activity 
(air  defense  free  Fire  zones,  saFe  corridors,  etc.)  would  also  be 
provided  to  ATALARS  as  part  of  the  normal  dissemination  of  such  data 
within  the  TAGS. 

ATALARS  would  monitor  the  air  activity,  exercising  control  as 
necessary  to  cope  with  accidental  deviations  From  Flight  plans, 
necessary  deviations  from  plans  due  to  changes  in  -irbase  status  or 
other  Factors,  and  the  routine  sequencing  and  spacing  problems 
associated  with  landing  and  takeoff  operations. 

The  unique  feature  of  ATALARS  operations  would  be  the  employment 
of  an  interface  between  the  aircraft  and  the  ground  control  facility 
which  allows  for  allocation  of  the  control  function  among  the 
aircraft  commander,  ground  controller,  and  automated  support.  As  an 
example,  an  aircraft  returning  as  planned  From  a  mission,  can 
automatically  be  provided  information  regarding  other  aircraft  in 
the  air  corridor  to  allow  the  aircraft  commander  to  maintain 
appropriate  spacing.  Alternatively,  presence  of  enemy  aircraft  in 
the  airspace  may  require  intervention  of  the  ground  controller. 

5.1  AIRCRAFT  ACTIVITY 

The  following  subsections  discuss  ATALARS  operations  in  the 
context  of  various  types  of  aircraft  activity  in  the  assigned 
airspace.  The  primary  responsibilities  of  ATALARS  comprise 
departing,  returning,  and  landing  aircraft.  However,  ATALARS  must 
be  capable  of  dealing  with  other  activity  in  its  airspace  as  well. 
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5.1.1  Transiting  Aircraft 


Since  ATALARS  performs  primarily  as  an  ATC  airbase  facility, 
there  should  be  few  aircraft  transiting  the  assigned  airspace.  The 
possibility  could  exist  primarily  because  of  the  multiple  airbase 
responsibility  of  ATALARS.  In  general,  ATALARS  would  accept  handoff 
on  entry,  flight-follow,  and  then  handoff  on  exit.  Control  would  be 
exercised  if  flight  following  showed  a  deviation  from  flight  plan  or 
a  situation  developed  requiring  a  deviation  from  flight  plan. 

5 . 1 . 2  Aircraft  Performing  Missions 

It  is  improbable,  but  conceivable  that  aircraft  would  be 
performing  missions  (e.g.,  tankers  providing  refueling,  combat  air 
patrol  operations,  orbiting  reconnaissance  platforms)  in  ATALARS 
assigned  airspace.  ATAlflRS  would  monitor  but  not  support  the 
activity.  The  airspace  involved  would  be  designated  for  that  use 
and  ATALARS  would  exercise  control,  only  if  the  activity  began  to 
drift  outside  the  assigned  airspace.  On  completion  of  the  mission, 
the  aircraft  would  be  treated  as  a  transiting  or  landing  aircraft. 

Other  types  of  missions  (e.g.,  air  defense  intercept,  ground 
attack)  which  might  take  place  in  ATALARS  assigned  airspace  would  be 
monitored  with  the  intent  of  rerouting  traffic  away  from  the 
activity  if  necessary. 

5.1.3  Aircraft  Returning  to  Base 

Aircraft  returning  as  planned  to  a  fully  operational  base  are 
treated  much  like  transiting  aircraft.  ATALARS  would  accept  the 
handoff,  flight  follow,  and  handoff  to  the  airbase  ATC  facilities. 
ATALARS  could  adjust  the  sequencing/spacing  of  aircraft  arriving  at 
the  handoff  transition  point, 

In  a  severely  degraded  environment,  ATALARS  would  assist  the 
returning  aircraft  by  identifying  a  suitable  landing  strip  and 
routing  the  aircraft  to  the  area  as  well  as  assuring  the 
sequencing/spacing  of  aircraft  arriving  in  the  area  of  the  strip. 

5.1.4  Landing  Aircraft 

In  the  event  of  landing  delays,  ATALARS  would  establish  an 
actual  (or  virtual)  stack,  inserting  and  extracting  aircraft  as 
appropriate.  If  necessary,  ATALARS  would  provide  guidance  from 
stack  extraction  to  the  landing  gate  defined  by  the  landing  systems 
usable  by  the  aircraft. 

5 . 1 . 5  Departing  Aircraf t 

After  takeoff,  a  departing  aircraft  is  treated  like  a  transiting 
aircraft.  If  necessary,  ATALARS  would  schedule  runway  utilization 
(takeoffs  and  landings)  to  accommodate  planned  operations  and 
emergencies . 
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5.1.6  Taxiing  Aircraft. 


Ground  traffic,  whether  at  an  airbase  or  autobahn  strip,  will 
not  generally  be  the  responsible ity  of  A'lALARS.  However,  in 
degraded  conditions  where  ground  traffic  congestion  affects 
landing/takeoff  scheduling,  ATALARS  must  maintain  an  awareness  of 
the  situation  and  may  be  required  to  assist  in  alleviating  the 
congestion  or  controlling  the  impact. 

5.2  CONTROL  MODES 

ATALARS  will  operate  in  three  different  modes: 

1.  Automated  Guidance  (e.g.,  collision  avoidance,  sequencing/ 
separation,  landing) 

2.  Pilot  Control  Support  (e.g.,  stack  insertion,  collision 
avoidance) 

3.  Ground  Controller  Support  (e.g.,  landing  scheduling) 

5.2.1  Automated  Guidance 

Under  relatively  routine  conditions,  ATALARS  Automated  Data 
Processing  (ADP)  (ground  based  and  on  board  the  aircraft)  will 
generate  guidance  information  for  the  aircraft  commander  and  provide 
sufficient  supporting  data  to  allow  aircraft  commander  assessment  of 
the  guidance.  The  specific  requirements  of  the  aircraft  (e.g., 
transit  of  the  ATALARS  airspace  via  a  particular  corridor,  return  to 
a  particular  airbase)  would  bo  defined  for  the  ATALARS  directly  or 
by  reference  to  planning  data.  ATALARS  would  flight  follow  the 
aircraft  (based  on  aircraft  reporting),  providing  direction  as 
required  to  assure  safe  separation,  provide  appropriate 
sequencing/spacing,  avoid  accidental  course  or  altitude  deviations, 
and  assure  proper  positioning  (e.g.,  approaching  a  landing  gate). 

As  appropriate,  ATALARS  would  provide  traffic  and  other  information 
relevant  to  the  activity  of  the  aircraft. 

5.2.2  Pilot  Control  Support 

In  this  mode,  ATALARS  acts  as  a  decision  aid  for  the  aircraft 
commander  with  respect  to  ATC  related  actions.  As  an  example, 
ATALARS  could  present  the  returning  aircraft  commander  with 
alternative  airstrips,  routing  to  the  selected  airstrip,  open 
landing  slots/stack  positions,  etc.  In  effect,  A7ALARS  identifies 
alternatives  and  provides  information  relevant  to  the  aircraft 
commander's  selection  of  the  alternative.  As  the  decision  is  made, 
ATALARS  provides  guidance  and/or  presents  ensuing  alternatives. 

5.2.3  Ground  Controller  Support 

Ground  controllers  exercise  control  by  exception  (e.g., 
emergencies),  in  response  to  changing  situations  (e.g.,  weather), 
and  in  terms  of  managing  the  utilization  of  the  airspace  (e.g.. 
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defining  corridors).  The  ATALARS  ADR  system  will  support  these 
activities  by  identifying  the  need  For  controller  action,  aiding  tho 
controller  decision  making,  and  assisting  in  setting  up  the 
mechanisms  to  allow  control  to  revert  to  the  other  modes. 

5.3  OTHER  CONSIDERATIONS 

The  ATALARS  concepL  has  been  developed  on  the  basis  of  a 
comparatively  "clean"  operational  environment.  Aircraft  are  assumed 
to  be  equipped  with  capabilities  such  as  the  JTIDS,  HADE  QUICK 
radios,  GPS,  and  Microwave  Landing  System  (MLS).  Landing  areas  are 
MLS  equipped.  Surveillance  data  is  available  via  digital  data  link 
from  other  sources.  An  actual  tactical  environment  may  vary 
substantially  from  this  ideal.  Host  country  and  allied  air  forces 
may  have  substantially  different  avionics  suites.  Civil  aircraft 
may  be  a  factor.  Older  surveillance  systems  may  be  in  use  or 
communications  interoperability  problems  may  exist.  Airfields  may 
use  different  landing  guidance  systems.  These  factors  contribute  to 
questioning  the  operational,  as  opposed  to  the  technical, 
feasibility  of  the  ATALARS  concept.  It  was  not  the  intent  of  this 
study  to  address  the  issues  raised  by  these  factors  in  detail. 

Their  resolution  will  be  based  on  a  combination  of  operational 
procedures,  system  design,  and  possibly  even  complementary 
acquisitions  as  ATALARS  moves  along  the  acquisition  life  cycle. 

Thus,  in  general,  the  following  sections  assume  a  comparatively 
"clean"  operational  environment. 


SECTION  6.0 
MISSION  FUNCTIONS 


Any  system  can  be  considered  a  functional  entity  composed  of 
personnel,  facilities,  hardware,  software,  databases,  and  a.L'1  other 
components  of  the  system.  This  entity,  independent  of  actual 
design,  must  perform  certain  functions  in  order  to  meet  the  required 
operational  capability  described  in  documents  such  as  Statements  of 
Need,  Concepts  of  Operations,  etc.  This  section  describes  the 
functions  of  ATALARS  in  a  hierarchical  context  as  derived  from  a  top 
down  structured  analysis.  The  methodology  used  is  described  in 
Appendix  A.  Subsequent  design  efforts  will  re-aggregate  and 
allocate  lower  level  functions  into  functional  subsystems.  For 
example,  all  functions  involving  weather  monitoring  may  be  combined 
into  one  function,  and  the  elements  thereof  allocated  first  between 
rnan  and  machine  and  then  further  allocated  to  the  physical 
subsystems  of  the  machine,  e.g.,  communications  processors,  data 
processor,  database,  display,  database  management  system  (DBMS) , 
etc.  Thus,  the  descriptions  presented  in  this  section  merely 
address  the  requirements  of  the  functional  entity,  ATALARS. 
Subsequent  efforts  will  resolve  design  issues  such  as  whether  the 
database  requirements  must  be  satisfied  with  a  fully  automated 
database  or  a  mixture  of  hard  copy  and  automation,  or  whether  manual 
intervention  is  required  prior  to  issuing  certain  traffic  control 
instructions . 

As  described  in  Section  5.0,  ATALARS  is  responsible  for 
managing/controlling  air  traffic  in  a  defined  airspace  (ATALARS 
Control  Zone)  to  the  extent  necessitated  by  absence  or  degradation 
of  facilities  and  systems  normally  responsible.  From  a  functional 
standpoint,  ATALARS  must  be  capable  of  all  airspace  management  and 
air  traffic  control  functions  in  its  assigned  airspace  and,  at  the 
same  time,  it  must  interface  with  those  existing/remaining 
facilities  and  systems  p_ rf oririing  functions  that  ATALARS  could 
perform.  Thus,  provisions  are  made  for  both  performing  a  function 
or  for  handoffs  to/from  ATALARS  from/to  other  systems  performing 
that  function. 

The  following  subsections  describe  ATALARS  in  terms  of  four 
primary  functions:  airspace  management,  approach  control,  airfield 
traffic  control,  and  exercise/training .  Figure  6-1  illustrates  the 
definition  of  the  first  three  in  terms  of  the  type  of  aircraft 
activity  that  the  function  addresses.  Airspace  management  addresses 
all  aircraft  activity  except  that  associated  with  landing  and  ground 
activity  at  the  airfield.  Approach  control  deals  with  aircraft 
intending  to  land  within  the  airspace.  Airfield  traffic  control 
addresses  runway  and  taxiway  activity  as  well  as  aircraft  on  final 
approach . 

Each  of  these  functions  generically  decompose  into  a  set  of 
planning,  situation  monitoring,  traffic  monitoring,  and  traffic 
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ATALARS  FUNCTION 

AIRCRAFT  ACTIVITY* 

AIRSPACE  MANAGEMENT 

-  TRANSITING 

-  ENTERING  THE  AIRSPACE 

-  EXITING  THE  AIRSPACE 

-  PERFORMING  MISSIONS 

-  ORBITERS  (e.g., 

Reconais sance  Platforms) 

-  REFUELING 

-  OTHER 

APPROACH  CONTROL 

-  RETURNING  TO  BASE 

-  APPROACHING  A  LANDING  GATE 

-  PRIOR  TO  LANDING 

-  TRANSITION  TO  AIRFIELD  OR 
HOLDING  AREA 

AIRFIELD  TRAFFIC  CONTROL 

-  LANDING 

-  DEPARTING 

-  TAXIING 

*1N  A  GIVEN  TACTICAL  SITUATION  ATALARS  MAY  BE  RESPONSBILE  FOR  ANY 
SUBSET  OF  THESE  ACTIUIl'IES. 


FIGURE  6-1 

CORRELATION  OF  ATALARS  FUNCTIONS  AND  AIRCRAFT  ACTIVITY 
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control  functions.  Planning  may  be  comparatively  long  term  (e.g., 
for  the  next  operations  cycle)  or  short  term  (e.g.,  in  response  to 
the  effects  of  an  enemy  attack  on  ar  airbase).  Situation  monitoring 
involves  monitoring  the  combined  traffic  activity  (e.g.,  corridor 
utilization)  and  factors  potentially  affecting  that  activity  (e.g., 
weather).  Traffic  monitoring  consists  of  maintaining  status  and 
tracks  on  aircraft.  Traffic  control  is  generally  exercised  in 
response  to  required  deviations  from  plans  (e.g.,  an  airfield  can  no 
longer  be  used  or  aircraft  with  an  emergency),  to  prevent 
unintentional  and  potentially  dangerous  deviations  from  plans  (e.g., 
aircraft  drifting  out  of  corridor),  and  to  resolve  actual/potential 
problems  (e.g.,  sequencing  and  spacing  of  aircraft  Tor  landing  or 
aircraft  closing  on  a  collision  course) . 

The  following  subsections  describe  this  decomposition  to  a  level 
of  detail  consistent  with  avoiding  premature  design  decisions. 
Appendix  B  provides  a  listing  of  the  total  hierarchical  structure. 

It  is  recommended  that  the  reader  review  the  Appendix  prior  to 
continuing  with  this  section  and  periodically  reference  it  in  order 
to  provide  a  contextual  overview  for  the  following  discussions. 

6.1  AIRSPACE  MANAGEMENT 

This  section  describes  the  functional  requirements  for 
p.l?"'ning/coordination ,  environment  monitoring,  air  traffic 
mo>  oring,  and  air  traffic  control  for  the  airspace  management 
fu  ion.  (See  Figure  6-2) 

6,1.  Planning /Coordination 

When  assigned  a  mission  from  HQ  TAF/TACC,  an  ATALARS  would  be 
activated  at  a  given  location  (latitude  and  longitude)  providing  the 
bases  or  airfields  within  designated  boundaries  with  an  ATALARS 
capability.  Abutting  or  overlapping  control  authorities  such  as  a 
Control  and  Reporting  Center  (CRC)  would  be  identified  along  with 
any  functional  limitations  or  extensions  relative  to  ATALARS 
func Lions.  The  ATALARS  database  would  be  initialized  given  the 
assigned  boundaries  and  limitations.  Appropriate  ATALARS  functions 
would  be  enabled  and  this  information  coordinated  with  all.  external 
interfaces  including  other  elements  of  the  TAGS  (e.g.,  the  Airborne 
Warning  and  Control  System  (AWACS)),  Army  and  Airbase  Air  Defense 
Systems  and  any  remaining  Base/Airfield  ATC  systems. 

ATALARS  will  establish  coordination  procedures  with  the  external 
interfaces  and  define  the  functions  to  be  exercised  by  ATALARS 
within  the  given  boundary  locations.  This  process  allows  ATALARS  to 
physically  and  functionally  integrate  itself  with  existing  ATC 
facilities/capabilities  and  allows  for  a  smooth  and  efficient 
coordination  with  these  systems  and  their  functions,  1  he  primary 
purpose  is  to  ensure  that  all  functions  are  sufficiently  addressed, 
but  not  duplicated,  ATALARS  will  update  its  databases  and 
activate/inhibit  appropriate  functions  upon  system  initialization,  a 
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change  in  status  (operation)  of'  any  exi string  ATC  function,  or  a 
change  in  functional  mission  requirements .  Redundant  ATALARS 
functions  will  ensure  a  survivable  system  providing  full  ATC 
services . 

6 . 1 . 2  Environment  Monitoring 

In  order  to  provide  adequate  and  accurate  ATC  support,  the 
A  f A  LARS  is  required  to  monitor  the  environment  in  which  the  system 
is  operating.  Changes  in  the  environment  will  affect  the  functions 
that  ATALARS  must  perform  as  well  as  the  degree  to  which  flight 
plans  can  be  followed. 

6  .  t .  2  .  1  Weather 

Weather  reporting,  predicting,  and  forecasting  are  performed  at 
airbase  or  other  local  Air  Weather  Service  (AWS)  services.  Reports 
from  aircraft  provide  additional  data.  ATALARS  will  receive  and 
review  AWS  and  pilot  reports  to  establish  and  maintain  a  weather 
database.  This  database  will  bo  continually  updated  to  provide  the 
most  recent  weather  conditions  to  pilots  and  controllers  when 
requested.  Any  ATALARS  function  affected  by  weather  can  access 
weather  information  through  the  database.  tn  addition,  weather 
advisories  can  be  issued  on  a  general  basis  to  aircraft  and 
controllers  to  ensure  that  affected  parties  are  aware  of  critical 
weather  conditions. 

6 . 1 . 2 . 2  Enemy  Activity 

Enemy  activity  within  ATALARS  airspace  is  monitored  through  a 
database  which  contains  the  identification  and  location  of  all 
threats.  Information  concerning  threats  in  the  area  is  obtained 
through  either  pilot  reports  or  air  defense  systems  notifications. 
The  database  is  updated  as  new  threats  are  identified  or  as  known 
threats  change.  Unidentified  aircraft  are  treated  initially  as 
threats  by  the  ATALARS  automation  system.  Threat  advisories  are 
issued  to  ensure  the  widest  possible  dissemination  of  warnings  to 
appropriate  systems  (aircraft  or  air  defense).  Routing  functions 
use  the  data  to  route  friendly  traffic  around  enemy  activity. 

6  . 1 . 2 , 3  Airspace  Utilization 

Definition  of  restricted  airspaces,  corridors,  and  other 
controlled  airspaces  are  maintained  by  the  ATALARS  database  to 
enable  theater  operations  and  ATALARS  functions  to  be  performed  on  a 
non-interference  basis.  The  airspace  utilization  function  acts  to 
monitor  the  aircraft  activity  in  those  areas  to  identify  potential 
problems  (e.g.,  overcrowding) . 

6 , 1 . 2 , 4  friendly  Air  Defense 

Conflicts  between  friendly  aircraft  and  friendly  air  defenses 
(e.g.,  flying  into  free  fire  zones)  are  avoided  by  monitoring  air 


-23 


I 

I 

I 

I 

I 

I 


■ 

■ 


defense  activities.  Current  information  on  air  defense  actiuili.es 
and  rules  of  engagement  (ROE)  are  prouided  to  and  maintained  by 
ATALARS  with  aduisories  sent  to  affected  aircraft.  ATALARS  must  bo 
notified  of  changes  in  deployment  and  ROE.  Conuersely,  routing 
functions  that  route  aircraft  into  defended  airspace  must  notify  the 
appropriate  air  defense  sysi_em. 

6 . 1 . 3  Air  Traffic  Monitoring 

Air  traffic  monitoring  includes  the  requirements  for  aircraft 
tracking,  aircraft  identification,  and  emergency  detection/ 
assessment . 

6 . 1 .  3  .  1  Aircraft  Tracking 

In  order  to  maintain  control  of  an  aircraft,  it  is  necessary  to 
track  that  aircraft.  Establishing  and  maintaining  a  track  on  all 
aircraft  within  ATALARS  airspace  allows  ATALARS  to  maintain  control 
of  the  entire  airspace.  A  track  on  each  aircraft  is  established  and 
maintained  from  a  uariety  of  sources.  GPS  and  relative  navigation 
information  from  the  aircraft,  position  information  from  an  external 
source  such  as  the  air  defense  system  or  AWACS,  an  interfacing 
authority  handoff,  as  well  as  takeoff  and  touchdown  notification, 
all  proui.de  track  information  pertinent  to  the  ATALARS  database. 

Note  that  track  information  from  multiple  sources  requires  ATALARS 
to  correlate  track  data  and  select  the  best  (most  accurate)  source. 

The  tracking  process  then  consists  of  checking  the  new 
information  for  ualidity,  consistency,  and  error  tolerances  and 
updating  the  database  to  reflect  the  new  information.  This  track 
information  is  shared  with  the  air  defense  system  in  keeping  with 
the  air  defense  coordination  mentioned  in  6. 1.2.4.  There  is  also 
internal  ATALARS  coordination  to  ensure  that,  a  positiue  track  is 
established  on  an  identified  aircraft  and  that  all  tracked  aircraft 
can  be  identified.  Finally,  the  tracking  function  flags  the 
database  for  aircraft  exiting  ATALARS  airspace  so  that  ATALARS 
functions  do  not  proceed  out  of  scope. 

6  .  1 .  3 . 2  Aircraft  Identif icati on 

In  parallel  with  the  tracking  function,  ATALARS  is  required  to 
positiuely  identify  the  aircraft.  The  identification  function  is 
trigger  i  when  an  initial  transmission  is  made  by  an  aircraft  or 
when  an  aircraft  is  passed  to  ATALARS  control  by  an  interfacing 
authority.  In  other  cases  identification  is  prouided  by  the 
aircraft  itself  or  by  the  outside  source.  Depending  on  the  amount 
of  information  receiued  from  external  sources  and  its  relative 
completeness,  the  identification  function  will  attempt  to 
interrogate  the  aircraft  and  match  or  verify  the  information  with 
the  database  including  the  A  TO,  flight  plan,  Identification  Friend 
or  Foe  (IFF)  code,  and  any  unique  characteristics  of  the  aircraft. 
The  ualidity  of  the  interfacing  authority  will  also  be  uerified,  if 
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applicable.  Aircraft  identification  information  is  shared  with  the 
air  defense  system  to  maintain  coordination  between  ATALARS  and  air 
defense  functions.  An  internal  coordination  with  the  ATALARS 
tracking  function  ensures  all  tracked  aircraft  are  identified  and 
all  identified  aircraft  are  tracked.  Note  that  ATALARS  requires 
more  detailed  identification  than  just  "friendly".  In  order  to 
provide  appropriate  guidance,  ATALARS  must  know  the  flight  plan. 
Thus,  it  must  be  able  to  correlate  aircraft  identification  and 
flight  plan. 

6  .  1 .  3  .  3  Emergency  Detec tiori/Assessment 

Emergency  detection  is  a  monitoring  function  which  searches  the 
various  ATALARS  databases  for  problems.  In  particular,  it  compares 
the  environmental  data  to  the  track  data  to  anticipate  problems. 
(Potential  collisions  are  treated  in  Section  6.1.  *1.4)  Since 
monitoring  is  an  ongoing  process,  the  only  triggers  required  for  the 
situation  detection  function  are  clock  inputs.  Severe  environmental 
changes  may  also  trigger  this  function.  However,  provisions  are 
also  made  to  have  the  aircraft  monitor  its  own  situation  as  well  as 
have  ATALARS  monitoring  the  situation  for  the  aircraft.  Thus,  a 
pilot  initiated  distress  call  also  serves  as  a  trigger.  Within  the 
ATALARS  database,  information  such  as  current  aircraft  locations, 
aircraft  routing,  airspace  allocations  (restricted  or  controlled), 
threat,  and  weather  conditions  are  addressed  concurrently .  The 
database  is  searched  for  threatening  or  dangerous  conditions 
resulting  from  the  interaction  of  all  the  available  data,  and  any 
conditions  found  are  highlighted  for  correction  or  reaction.  Route 
deviations  or  other  exceptions  which  may  affect  the  mission  or 
safety  of  aircraft  within  ATALARS  airspace  are  also  highlighted. 
Highlighted  conditions  are  then  assessed  at  a  severity  level  to 
establish  appropriate  priorities.  Based  on  these  ass^sed 
priorities,  the  condition  is  passed  to  either  the  traffic  control 
function  (routine  course  corrections)  or  the  emergency  response 
function  as  well  as  alerting  the  aircraft  commander  to  the  nature  of 
the  detected  condition. 

6.1.4-  Air  Traffic  Control 

Air  traffic  control  within  the  airspace  management  function 
includes  aircraft  handoff,  aircraft  routing,  aircraft  sequencing  and 
spacing,  and  emergency  response. 

6 . 1 . 4 . 1  Aircraft  Handoff 

Acceptance  of  a  handoff  from  an  external  source  acts  to 
.initialize  the  implementation  of  ATALARS  functions  for  the 
aircraft.  Handoff  to  an  external  source  stops  the  performance  of 
ATALARS  functions.  Once  an  aircraft  .is  identified,  and  the 
identification  is  correlated  with  a  track,  a  record  is  established 
in  the  ATALARS  database.  This  record  .is  used  to  access  any  further 
information  on  that  aircraft  by  the  functions  which  follow.  If 
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necessary,  the  aircraft  is  provided  with  information  to  establish 
communications  with  ATALARS.  As  long  as  the  record  is  appropriately 
flagged,  the  system  will  process  the  appropriate  control 
information.  When  the  tracking  function  determines  the  aircraft  to 
be  exiting  ATALARS  airspace,  this  function  will  be  provided  with 
details  of  the  boundary  through  which  the  aircraft  will  pass.  The 
aircraft  will  then  be  removed  from  under  ATALARS  control,  and 
handed-off  to  the  appropriate  interfacing  authority. 

Internal  handoffs  will  occur  from  the  airspace  management 
function  to  approach  control  and  from  airfield  traffic  control  (on 
takeoff)  to  airspace  management. 

6  .  3  .  4 . 2  Aircraft  Routing  Control 

Once  ATALARS  has  acquired  the  aircraft  it  is  necessary  to 
establish  a  safe,  efficient  route  within  ATALARS  airspace.  The 
aircraft  routing  function  determines  this  route  based  on  the 
aircraft's  flight  plan,  other  aircraft  in  the  airspace,  the  status 
of  the  aircraft,  approach  control  requirements  (sequencing  and 
spacing),  status  of  the  base  or  airfield,  weather,  threat  location, 
and  restricted  or  controlled  airspace  locations.  The  determined 
route  (including  speed)  is  used  to  update  the  database  containing 
all  routes  within  ATALARS  airspace.  The  appropriate  guidance  is 
provided  to  the  aircraft  in  ord. r  to  maintain  the  planned  route 
until  control  is  transferred.  At  any  time,  a  route  interrupt  may  be 
received  from  an  emergency  detection  function  (e.g.,  increasing 
weather  severity),  indicating  that  the  current  route  cannot  be 
completed  in  a  safe  and  efficient  manner.  i his  route  interrupt  will 
cause  a  new  route  to  be  developed  given  the  new  conditions  and  a 
subsequent  update  to  the  ATALARS  database. 

6 . 1 . 4 . 3  Aircraft  Sequencing  and  Spacing 

If,  during  the  progress  of  the  aircraft,  there  is  a  degradation 
of  route  safety  or  a  change  in  approach  control  or  mission 
requirements,  there  may  be  need  to  temporarily  deviate  from  the 
planned  route  (or  speed)  while  maintaining  the  overall  route 
mission.  The  sequencing  and  spacing  function  attempts  to  maintain 
the  sequencing  and  spacing  established  by  the  routing  function. 

Like  the  routing  function,  sequencing  and  spacing  considers  factors 
such  as  the  aircraft's  flight  plan,  approach  control  requirements, 
etc.,  to  determine  the  actual  route  r’eviations  required.  Based  on 
the  relative  success  of  this  analysis  in  responding  to  the  changes 
required,  this  function  will  finalize  and  issue  instructions  that 
will  temporarily  alter  the  current  route  or  instigate  a  route 
interrupt  and  pass  the  function  back  to  aircraft  routing. 

6 . 1 . 4 . 4  Emergency  Response 

When  an  emergency  is  detected  (e.g.,  potential  mid-air 
collision),  information  concerning  identification  and  positioning  of 
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the  threat  or  condition  is  passed  to  the  emergency  response 
function.  The  emergency  response  function  is  activated  not  so  much 
by  specific  conditions  or  threats  as  it  is  by  time  critical 
situations.  Its  purpose  is  to  determine  reactions  required  to  avoid 
immediate  or  imminent  dangers  including  an  enemy  attack  or  a  inid-air 
collision.  Because  it  must  deal  with  any  situation  requiring 
immediate  reaction,  this  function  must  access  eve^y  database  which 
holds  information  concerning  the  airspace  and  activities  within  the 
airspace  as  well  as  system  capabilities  and  status.  After 
determining  the  reactions  required,  the  emergency  response  function 
will  issue  avoidance  and  recovery  instructions  to  the  aircraft. 

Once  the  threat  or  dangerous  condition  is  diminished,  recovery 
instructions  may  prove  out  of  scope  for  this  function.  If  this 
occurs,  the  function  will  pass  to  the  sequencing  and  spacing 
function  or  the  appropriate  approach  control  function  for  a  more 
comprehensive  recovery  sequence. 

If  the  aircraft  commander  reacts  prior  to  instructions  from 
ATALARS  or  in  a  different  manner,  the  routing  control  function  (or 
emergency  detection  function)  will  note  the  deviation  and  institute 
a  recovery  sequence. 

6.2  APPROACH  CONTROL 

The  approach  control  function  controls  the  timing  of  the  arrival 
of  aircraft  for  final  approach.  It  consists  of  two  categories: 
those  necessary  to  establish  the  route  parameters  for  the  aircraft 
(Figure  6-3)  and  those  necessary  to  cope  with  traffic  congestion 
beyond  that  which  can  be  handled  with  minor  sequencing  and  spacing 
adjustment.  This  includes  virtual  or  actual  stacking  of  aircraft 
awaiting  landing.  (Virtual  stacking  as  used  here  covers  adjusting 
aircraft  flight  profiles  to  assure  appropriate  arrival  time.  Actual 
stacking  would  involve  making  provisions  for  aircraft  to  hold  in  a 
particular  area.)  Approach  control  may  involve  apportioning 
returning  aircraft  between  airbases  and  landing  strips  in  the  event 
airfield  servicability  has  been  detrimentally  affected.  This 
involves  selecting  airbases  and  defining  routes  (or  corridors)  for 
returning  aircraft  to  approach  the  airbases.  The  function  must  also 
accommodate  aircraft  with  emergency  conditions  (emergency  fuel, 
battle  damage),  and  provide  airbase  selection,  routing,  and 
scheduling  support. 

In  a  comparatively  benign  environment  where  operations  are 
progressing  smoothly  as  planned,  this  function  is  virtually 
inactive.  The  function  merely  verifies  that  return  to  base  can 
proceed  as  planned.  l'he  airspace  management  function  (sequencing 
and  spacing)  will  provide  any  minor  adjustments  required  prior  to 
final  approach.  Handoff  will  be  made  to  the  airfield  traffic 
control  function  for  final  approach.  In  the  less  benign 
environment,  the  approach  control  function  may  be  extensively 
exercised . 
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The  approach  control  function  consists  of  four  major 
sub-functions : 

1)  Aircraft  Route  Selection  --  Reviews  current  mission  plans  and 
airbase  status  to  support  the  airbase  selection  process.  Also 
reviews  current  air  traffic  situation  and  other  factors  (weather)  to 
support  route  selection. 

2)  Approach  Environment  Monitoring  -  Monitors  and  provides 
status  of  changing  conditions  in  weather,  enemy  activity,  friendly 
air  defenses,  and  interfacing  control  systems.  Identifies  emergency 
conditions . 

3)  Stack  Operations  Monitoring  -  Upon  receipt  of  handoff  from 
airspace  management,  stack  operations  monitoring  will  continue  to 
track  the  aircraft  through  handoff  to  the  airfield  traffic  control 
function.  Also  identifies  emergency  (or  out-of-parameter) 
conditions . 

4)  Stack  Operations  Control  -  Upon  handoff  from  the  airspace 
management,  the  stack  operations  control  function  will  provide 
guidance  and  direction  as  required  to  the  aircraft.  It  will, 
maintain  control  until  handoff  to  the  airfield  traffic  control 

f  unction . 

6 . 2 . 1  Aircraft  Route  Selection 

When  an  aircraft  enters  the  ATALARS  control  zone  with  the  intent 
to  land,  the  aircraft  route  selection  function  assesses  the  aircraft 
requirements  and  primary  base  status  to  determine  whether  problems 
currently  exist  that  would  prohibit  the  aircraft  or  group  of 
aircraft  from  landing.  Once  this  has  been  accomplished,  the  ATALARS 
has  either  verified  that  the  flight  plan  can  be  followed  or 
determined  that  a  change  is  required.  If  the  aircraft  situation  was 
critical,  another  base  nearer  may  be  sought  to  allow  the  aircraft  to 
land.  If  the  primary  base  was  either  under  minimum  weather 
conditions  or  enemy  attack,  alternative  bases  may  be  requested.  Che 
product  of  this  analysis  is  a  matching  of  aircraft  requirements  to 
available  airbases.  (See  figure  6-4) 

following  airbase  selection,  the  current  situation  with  respect 
to  routing  would  be  analyzed.  The  first  function  to  be  exercised 
would  be  the  airspace  environment  analysis.  Changes  to  friendly  air 
defenses,  controlled  corridors,  weather  conditions  between  the 
aircraft  and  the  base,  and  enemy  activity  relative  to  the  transit 
corridor,  aircraft,  and  base  would  be  analyzed  for  potential  impact 
on  route  selection. 

Following  the  analysis  of  the  environment,  the  au.r  traffic 
situation  would  be  reviewed.  This  analysis  would  take  inp"ts  from 
the  various  traffic  monitoring  functions  and  analyze  the  du<.a 
relative  to  potential  routes  for  the  aircraft  that  has  entered  the 
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FIGURE  6-4 

AIRCRAFT  ROUTE  SELECTION 


ATALARS  control  zone.  From  this  data,  the  route  selection  function 
can  either  verify  the  flight  plan  or  provide  recommendations  for 
correcting  the  route  that  should  be  followed  to  return  to  the 
selected  base.  Once  this  function  has  completed  the  analysis,  all 
the  main  parameters  have  been  determined  and  coordinated  as  a  plan. 

Data  provided  by  this  function  will,  allow  the  airspace 
management  function  to  time  sequence  the  aircraft  to  properly  enter 
and  follow  its  approved  transit  corridor  to  the  handoff  window  of 
the  stack  controller. 

6 . 2 . 1 .  1  Airbase  Selection 

The  airbase  selection  function  assesses  two  factors  in  its 
analysis.  They  are:  the  aircraft's  capability  to  follow  the  flight 
plan  to  its  intended  landing  base,  and  whether  the  conditions  at  the 
planned  base  will  permit  the  aircraft  to  land. 

Responses  are  provided  by  the  aircraft  requirements  assessment 
and  the  airbase  status  review  functions.  When  the  analysis  has  been 
completed  by  these  functions,  the  exact  status  of  the  aircraft  is 
known  and,  if  necessary,  an  alternate  base  is  chosen.  If  there  is 
no  change  to  the  flight  plan,  ATALARS  will  just  perforin  a 
verification  that  the  flight  plan  is  viable. 

The  airbase  selection  function  consists  of  sub-functions  for 
aircraft  requirements  assessment,  airbase  status  review,  and  finally 
the  airbase  selection. 


6 . 2 . 1 . 1 . 1  Aircraft  Requirements  Assessment 

Upon  notification  that  an  aircraft  is  entering  the  ATALARS 
control  zone  with  a  request  to  land,  the  aircraft  requirements 
assessment  function  would  request  the  status  of  the  aircraft. 
Information  provided  by  the  aircraft  would  be  position  data,  fuel 
status,  and  flying  status  of  the  aircraft.  If  there  are  either 
aircraft  commander  or  crew  injuries,  it  would  require  verbal 
communication  between  someone  aboard  the  aircraft  and  the  controller 
who  is  located  at.  the  ATALARS  van.  (This  information  would  bo 
manually  entered  by  the  controller  into  the  ATALARS). 


Where  the  airspace  management  function  has  identified  the 
aircraft  and  correlated  it  to  its  Flight  plan,  the  aircraft 
requirements  assessment  function  will  calculate  the  estimated  time 
of  arrival  (tTA)  per  the  flight  plan,  estimate  the  fuel  required  and 
compare  it  to  what  fuel  is  available  on  the  aircraft.  The  approach 
control  function  will  monitor  the  fuel  status  from  the  time  the 


aircraft  enters  the  control  zone  until  the  handoff  to  the  landing 
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the  situation  may  become  critical  at  any  point  in  time  due  to 


equipment  malfunctions  or  just  due  to  the  delays  caused  by  their 
location  in  the  stack.  If  fuel  or  any  other  factor  presents  a 
problem,  a  need  to  find  alternate  landing  facilities  is  established. 
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6.2. 1,1.2  Airbase  Status  Review 


If  the  aircraft  can  follow  the  flight  plan,  the  airbase  status 
review  function  will  query  the  primary  base  (mission  defined  base) 
for  anything  that  would  prohibit  the  aircraft  from  landing.  Data 
required  for  this  analysis  is  provided  by  the  approach  environment 
monitoring  function.  The  types  of  data  include  weather  conditions 
at  the  base,  enemy  activity  at  or  near  the  base,  changes  in  friendly 
air  defenses,  and  emergencies  at  or  near  the  base.  If  there  are  no 
problems  noted,  the  acceptability  of  the  base  would  be  verified. 

If  the  primary  base  cannot  be  used  or  the  aircraft  cannot  follow 
the  flight  plan  due  to  low  fuel  or  malfunctions,  the  status  of 
potential  alternates  is  reviewed  for  suitability. 

6 . 2 . 1 . 1 .  3  Airbase  Selection 

The  airbase  selection  function  is  triggered  for  one  of  two 
reasons.  Either  the  aircraft  which  entered  the  airspace  has  an 
emergency  situation  or  the  primary  base  has  a  condition  that  will 
not  permit  the  aircraft  to  land.  Based  on  the  aircraft's 
requirements  and  the  status  of  suitable  alternates,  a  list  of 
candidate  alternates  is  selected. 

6 . 2 . 1 .  2  Situation  Analysis 

This  function  is  composed  of  an  airspace  environment  analysis 
and  an  air  traffic  situation  analysis.  The  airspace  environment 
analysis  reviews  potential  aircraft  routes  for  conditions  that  may 
prohibit  the  return  of  the  aircraft.  Parameters  that  this  function 
would  review  include:  weather  conditions,  enemy  activity,  and 
emergency  situations.  The  air  traffic  situation  analysis  function 
will  determine  if  there  are  any  traffic  congestion  problems. 

6 . 2  . 1 . 2 . 1  Airspace  Environment  Analysis 

The  airspace  environment  analysis  function  reviews  the  airspace 
for  changes  in  weather  conditions,  encroaching  enemy  activity,  and 
for  changes  in  friendly  air  defenses.  The  purpose  of  this  function 
is  to  establish  the  corridors  that  returning  aircraft  may  transit 
with  the  least  difficulty.  In  other  words,  the  function  sets  up  the 
guidelines  where  aircraft  can  and  cannot  fly.  Changes  in  the 
airspace  environment  that  are  identified  when  this  function  is 
exercised  will  be  flagged  to  the  information  dissemination  function 
(6.2.5)  for  the  purpose  of  identifying  and  notifying  those  aircraft 
and  ground  systems  concerned.  This  would  include  aircraft  that  are 
deviating  from  their  approved  course. 

6 . 2 .  1 . 2 . 2  Air  Traffic  Situation  Analysis 

This  function  reviews  potential  routes  for  congestion  that  may 
adversely  impact  the  capability  of  the  aircraft  to  reach  the  landing 
area . 


6.2. 1.3  Route  Selection 


This  function  will  first  consider  the  flight  plan  as  the 
preferred  route.  If  an  alternate  route  is  required  because  of 
changes  to  aircraft  status  or  base  conditions,  this  function  mill 
use  the  results  of  the  above  analyses  (candidate  alternates  and 
potential  routing  problems)  to  establish  candidate  route/landing 
area  pairs.  These  would  be  prioritized  as  a  function  of  time 
required . 

After  the  analysis  has  been  completed,  the  route  selection 
function  would  provide  recommendations  to  the  aircraft  commander  or 
ATALARS  controller  for  a  decision. 

6 . 2 . 2  Approach  Environment  Monitoring 

The  approach  environment  monitoring  function  monitors  the 
ATALARS  control  zone  for  conditions  that  would  interrupt  or 
interfere  with  an  aircraft  in  a  stack  or  approaching  the  landing 
area.  It  also  issues  advisories  of  these  conditions  and  identifies 
emergency  situations. 

The  type  of  conditions  monitored  are: 

Weather  -  Fog,  wind,  wind  shears,  rain,  snow,  icing,  or 
anything  that  may  prohibit  an  aircraft  f rom  approaching  a  given 
base . 

Enemy  Activity  -Unidentified  and  enemy  aircraft  entering  the 
ATALARS  control  zone  engaged  in  battle  or  enroute  for  attack. 

The  ATALARS  control  zone  would  view  those  areas  as  restricted  to 
returning  aircraft. 

Friendly  Air  Defenses  -  Changes  in  coverage  or  rules  of 
engagement  would  be  identified  and  processed  by  the  ATALARS  for 
the  purposes  of  re-routing  aircraft. 

Interfacing  Control  Systems  -  Monitors  other  necessary  control 
functions  for  their  operational  status  (n.g.,  MLS  would  be 
monitored  for  landing  control  at  a  given  base,  etc.).  This 
function  lets  ATALARS  accommodate  itself  to  the  degradation  of 
any  interfacing  control  system  (ATC,  MLS,  RSU,  RAPCON,  etc.). 

6 , 2 . 2 . 1  Weather 

The  purpose  of  this  sub-function  is  to  monitor  the  weather 
conditions  in  the  ATALARS  control  zone  and  at  each  of  the  bases. 

The  weather  updates  will  be  checked  at  specific  time  intervals  to 
identify  major  problems  caused  by  local  weather  conditions.  The 
information  would  be  provided  to  the  other  ATALARS  functions  for  the 
purpose  of  redirecting  air  traffic  in  approach  corridors  or  stacks. 
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Outputs  from  this  function  will  be  utilized  in  either  confirming 
flight  plan  routing  or  in  determining  alternates.  These  outputs 
will  be  the  inputs  to  other  functions  such  as  base  selection,  stack 
control,  and  information  dissemination. 

6 . 2 . 2 . 2  Enemy  Activity 

This  function  monitors  all  enemy  activity  in  and  around  the 
perimeter  of  the  ATALARS  control  zone.  Inputs  are  provided  by 
external  sources  such  as  AWACS.  The  output  of  this  function  is  the 
exact  location  of  any  unfriendly  forces  and  any  other  relevant 
information  available.  This  information  will  bo  an  input  to  the 
route  selection  decision  process.  The  data  would  be  updated 
frequently  to  permit  corrections  as  the  situation  requires.  It 
would  also  be  used  to  respond  to  threats  to  aircraft  in  approach 
corridors  or  stacks. 

6 . 2 . 2 . 3  Friendly  Air  Defenses 

This  function  monitors  friendly  air  defenses  and  their  coverage 
zones.  In  addition,  the  rules  of  engagement  are  defined  prior  to 
the  mission  and  updated  as  required.  This  function  will  provide 
inputs  to  the  route  selection  process  for  the  purpose  of  verifying 
that  the  flight  plan  was  correct  or  for  the  decision  process 
required  in  revising  the  flight  plan.  It  also  assesses  potential 
problems  with  approach  corridors  and  stacks. 

6.2.2 .4  Interfacing  Control  Systems 

The  purpose  of  the  interfacing  control  systems  function  is  to 
monitor  the  status  of  each  of  the  control  and  landing  systems  with 
data  provided  from  the  airfield  status  monitoring  function  (6.3.2). 
As  the  capabilities  of  these  interfacing  system  degrade  either  due 
to  equipment  failure  or  due  to  enemy  action,  this  function  would 
phase  in  the  ATALARS  control  as  required.  The  database  must  include 
the  control  capability  at  each  base  within  the  ATALARS  control  zone. 

6 . 2 . 2 . 5  Emergency  Identification/Notification 

The  purpose  of  this  function  is  to  monitor  the  ATALARS  control 
zone  for  any  emergency  situation,  and  identify  the  type  of  emergency 
that  exists  with  its  appropriate  location.  The  types  of  emergencies 
that  would  be  identified  include:  wind  shear  problems,  aircraft 
being  vectored  too  close  to  each  other,  enemy  advances  into  the 
ATALARS  control  zone,  unplanned  changes  in  the  friendly  air 
defenses,  loss  of  communication  with  the  friendly  air  defenses,  loss 
of  the  air  traffic  control  capability,  and  loss  of  an  automated 
landing  systems  like  the  MLS. 

6 . 2 . 2 . 6  Issue  Advisories 

After  formal  identification  of  aircraft  entering  the  ATALARS 
control  zone,  the  first  query  to  the  approach  control  function  for 
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Outputs  from  this  function  will  be  utilized  in  either  confirming 
flight  plan  routing  or  in  determining  alternates.  These  outputs 
will  be  the  inputs  to  other  functions  such  as  base  selection,  stack 
control,  and  information  dissemination. 

6 . 2 . 2 . 2  Enemy  Activity 

This  function  monitors  all  enemy  activity  in  and  around  the 
perimeter  of  the  ATALARS  control  zone.  Inputs  are  provided  by 
external  sources  such  as  AWACS.  The  output  of  this  function  is  the 
exact  location  of  any  unfriendly  forces  and  any  other  relevant 
information  available.  This  information  will  be  an  input  to  the 
route  selection  decision  process.  The  data  would  be  updated 
frequently  to  permit  corrections  as  the  situation  requires .  It 
would  also  be  used  to  respond  to  threats  to  aircraft  in  approach 
corridors  or  stacks. 

6 . 2 . 2 . 3  friendly  Air  Defenses 

This  function  monitors  friendly  air  defenses  and  their  coverage 
zones.  In  addition,  the  rules  of  engagement  are  defined  prior  to 
the  mission  and  updated  as  required.  This  function  will  provide 
inputs  to  the  route  selection  process  for  the  purpose  of  verifying 
that  the  flight  plan  was  correct  or  for  the  decision  process 
required  in  revising  the  Flight  plan.  It  also  assesses  potential 
problems  with  approach  corridors  and  stacks. 

6 . 2 . 2 . 4  Interfacing  Control  Systems 

The  purpose  of  the  interfacing  control  systems  function  is  to 
monitor  the  status  of  each  of  the  control  and  landing  systems  with 
data  provided  from  the  airfield  status  monitoring  function  (6.3.2). 
As  the  capabilities  of  these  interfacing  system  degrade  either  due 
to  equipment  failure  or  due  to  enemy  action,  this  function  would 
phase  in  the  ATALARS  control  as  required.  The  database  must  include 
the  control  capability  at  each  base  within  the  ATALARS  control  zone. 

6 . 2 . 2 . 5  Emergency  Identification/Notification 

The  purpose  of  this  function  is  to  monitor  the  ATALARS  control 
zone  for  any  emergency  situation,  and  identify  the  type  of  emergency 
that  exists  with  its  appropriate  location.  The  types  of  emergencies 
that  would  be  identified  include:  wind  shear  problems,  aircraft 
being  vectored  too  close  to  each  other,  enemy  advances  into  the 
ATALARS  control  zone,  unplanned  changes  in  the  friendly  air 
defenses,  loss  of  communication  with  the  friendly  air  defenses,  loss 
of  the  air  traffic  control  capability,  and  loss  of  an  automated 
landing  systems  like  the  MLS. 

6 . 2 . 2 . 6  Issue  Advisories 

After  formal  identification  of  aircraft  entering  the  ATALARS 
control  zone,  the  first  query  to  the  approach  control  function  for 
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base  and  route  selection  will  be  followed  by  a  timed  and  dated 
message.  The  message  wall  update  the  pilot  on  the  environment. 

While  this  information  is  being  presented  to  the  pilot,  the  ATALARS 
approach  environment  m^^'.toring  functions  will  be  simultaneously 
updating  the  information  to  the  current  conditions. 

Updates  to  these  advisories  will  bo  made  each  time  significant 
changes  occur. 

6.2.3  Stack  Operations  Monitoring 

The  stack  operations  monitoring  function  monitors  all  aircraft 
within  the  ATALARS  control  zone  in  their  various  entry  and  holding 
locations . 

6 . 2 . 3 . 1  Aircraft  Tracking 

The  primary  purpose  of  this  function  is  to  continue  tracking  the 
aircraft  through  the  holding  stack  to  final  approach  at  which  time 
the  airfield  traffic  control  function  would  take  over. 

Outputs  from  this  function  would  be  utilized  in  time  sequencing 
aircraft  that  have  jusl  entered  the  ATALARS  control  zone  requesting 
landing  information.  In  addition,  this  information  would  be  used  to 
coordinate  between  the  airfield  traffic  control  function  and  the 
approach  control  function  for  time  sequencing  the  aircraft  that  are 
being  extracted  from  the  stack  for  landing. 

6 . 2 . 3 . 2  Emergency  Detection/ Assessment 

This  function  monitors  the  stacks  for  any  emergency  situations. 
Once  detected,  it  defines  the  type  of  emergency  and  assesses  the 
criticality . 

Following  the  assessment  of  the  emergency,  this  function  will 
trigger  those  functions  necessary  to  provide  assistance  to  the 
aircraft  involved.  Additionally,  a  flag  will  be  sent  to  the 
information  dissemination  function  to  assure  alerting  all  concerned 
parties , 

6 . 2 . 4  Stack  Operation  Control 

The  stack  operations  control  function  maintains  control  by 
guiding  the  aircraft  into  virtual  and  actual  stacks  and  handoffs  to 
the  ATALARS  landing  function.  This  control  function  is  comprised  of 
six  sub-functions: 

1)  Aircraft  Handoff  -  This  function  is  where  the  control  of  the 
aircraft  in  the  ATALARS  control  zone  is  either  handed  to  the 
stack  operation  control  or  handed  to  the  airfield  traffic 
control  function. 
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2)  Stack  Insertion  -  This  function  calculates  the  time  sequence, 
aircraft  velocity,  etc.  for  aircraft  to  be  inserted  into  the 
stack.  Additionally,  it  notes  the  spacing  required  in  order 
to  maintain  the  proper  flow  of  air  traffic  taking  off  and 
landing . 

3)  Stack  Traffic  Control.  -  This  function  maintains  control  of 
the  air  traffic  within  the  stack,  and  makes  changes  that  are 
necessary  to  keep  a  safe  separation  among  the  aircraft. 

4)  Stack  Extraction  -  This  function  provides  the  sequencing  and 
spacing  for  aircraft  to  land  at  a  given  base 

5)  Runway  Monitoring  -  This  function  monitors  the  runway  and 
provides  the  data  required  to  time  sequence/space  the 
aircraft  being  extracted  from  the  stack. 

6 )  Emergency  Response  -  This  function  takes  over  the  control  of 
vectoring  aircraft  out  and  around  emergency  situations. 

6 . 2 . 4 . 1  Aircraft  Handoff 

Within  the  approach  control  function,  the  aircraft  handoff  is 
being  accomplished  from  one  ATALARS  function  to  another.  Once  the 
airspace  management  function  has  completed  its  process,  the  control 
of  the  aircraft  would  be  handed  over  to  the  approach  control 
function.  The  second  time  the  handoff  of  control,  takes  place  is 
when  the  aircraft  has  been  extracted  from  either  the  virtual  or  the 
actual  stack.  Then  the  airspace  control  would  be  handed  to  the 
ATALARS  landing  control  function. 

6 . 2 . 4 . 2  Stack  Insertion 

The  stack  insertion  function  has  three  states  of  operation; 
virtual  stack  insertion,  actual  stack  insertion,  and  no  action 
required.  Virtual  stack  insertion  is  the  process  of  time  sequencing 
and  vectoring  the  aircraft  to  the  landing  base  location.  In  times 
of  light  aircraft  activity,  the  virtual  stack  may  be  the  only  timing 
and  spacing  required  to  get  the  aircraft  to  the  landing  gate. 
Insertion  of  aircraft  into  an  actual  stack  or  holding  area  would  be 
a  continuation  of  the  virtual  stack  process.  Instead  of  handing -off 
to  airfield  traffic  control,  the  stack  control,  function  would  assume 
control.  This  process  would  be  necessary  at  times  when  the  volume 
of  air  traffic  is  in  excess  of  what  the  landing  base(s)  can  handle 
during  a  given  period.  No  action  would  be  required  when  the 
aircraft  is  performing  according  to  the  intended  flight  plan  and  no 
air  traffic  or  environmental  problems  exist. 

6 . 2 . 4 . 3  Stack  Traffic  Control 

When  either  virtual  or  actual  stack  operations  are  required,  the 
stack  traffic  control  function  will  be  in  operation.  The  main 
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purpose  of  this  function  is  to  proui.de  the  direction  necessary  to 
orchestrate  the  stack  operation.  It  directs  changes  in  the  altitude 
or  position  to  eventually  bring  the  aircraft  to  its  planned 
extraction  point.  The  control  of  the  aircraft  in  an  emergency  would 
be  handed  directly  to  the  emergency  response  function  for  immediate 
action . 

fin  aircraft  that  starts  to  drift  out  of  the  assigned  pattern, 
provided  that  it  is  not  in  an  emergency  situation,  will  be  directed 
by  the  stack  traffic  control  function  to  return  to  its  approved 
holding  or  transit  corridor. 

6 . 2 . 4 . 4  Stack  Extraction 

In  both  the  virtual  stack  and  actual,  stack  operations,  the  stack 
extraction  function  would  be  utilized  to  properly  time  sequence  and 
space  the  aircraft  landing  at  a  given  airbase.  For-  this  function  to 
operate,  it  must  query  the  aircraft  tracking  function  and  the  runway 
monitoring  function  for  real  time  status.  Once  the  status  has  been 
assessed,  the  stack  extraction  function  will  direct  the  aircraft  to 
the  appropriate  window  to  its  final  landing  gate.  Simultaneously, 
the  stack  extraction  routine  would  trigger  the  information 
dissemination  function  to  notify  the  ATC  function  about  the  landing 
aircraf t . 

6 . 2 . 4 . 5  Runway  Monitoring 

The  runway  monitoring  Function  is  mainly  controlled  by  the 
airfield  traffic  control  function.  Data  from  this  function  which 
contains  traffic  traversing  the  runway  will  be  utilized  by  the  stack 
insertion  and  extraction  functions.  This  function  will  provide  the 
status  of  runway  usability,  (i,e.,  runway  battle  damage,  crashed 
aircraft,  ground  vehicles  blocking  the  runway,  or  barrier/cable 
status) . 

6 . 2 . 4 . 6  Emergency  Response 

The  primary  purpose  of  this  function  is  to  provide  direction  to 
the  aircraft  with  the  emergency  and,  iF  necessary,  expedite  the 
landing  of  the  aircraft.  Typical  types  of  emergencies  that  would 
require  a  reaction  are:  quick  changes  in  the  environment  (i.e., 
weather,  wind  shear  problems,  etc),  aircraft  with  damage  to  critical 
systems  and  collision  avoidance. 

6 . 2 . 5  Information  Dissemination 

This  function  disseminates  information  to  those  agencies  or 
aircraft  necessary  to  safely  complete  the  mission.  For  example,  in 
the  case  where  direction  has  been  given  to  an  aircraft  or  groups  of 
aircraft,  this  function  would  be  triggered  to  send  out  notification 
of  the  aircraft  entering  the  control  zones  to  the  air  traffic 
controllers,  friendly  air  defenses,  and  any  other  agency  required. 
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Triggering  of  this  function  may  be  accomplished  by  any  of  the 
ATALARS  functions. 

6 . 2 . 5  .  1  Aircraft  Not:i.f ication 

This  function  will  notify  the  pilot  of  major  changes  to  the 
mission  plan,  such  as  recent  changes  in  the  friendly  air  defense 
corridors,  location  of  existing  emergencies,  and  critical  changes  in 
weather . 

6 . 2  .  B  ,  2  Controller  Notification 

This  function  will  alert  the  controller  at  the  primary  landing 
base  that  there  is  an  aircraft  that  has  entered  the  control  zone 
with  an  intent  to  land  and  the  route  the  aircraft  is  expected  to 
follow.  Additionally,  the  status  of  the  aircraft  is  provided,  if  it 
is  in  an  emergency  situation. 

6 . 2 . B . 3  Air  Defense  Notification 

This  function  notifies  the  friendly  air  defenses  of  friendly 
aircraft  about  to  enter  their  coverage  zones. 

6.3  AIRFIELD  TRAFFIC  CONTROL 

This  section  describes  the  requirements  for  the  process  of 
scheduling  and  controlling  air  and  ground  traffic  at  airfields  in  an 
ATALARS  control  zone.  (See  Figure  6-B) 

6 . 3 . 1  Traffic  Scheduling 

Traffic  scheduling  is  the  processing  of  landing  and  takeoff 
requirements  (Figure  6-6)  and  results  in  the  assignment  of  a  time 
slot  for  each  aircraft  requesting  takeoff /landing . 

6 . 3  . 1 . 1  Landing  Requirements  Assessment 

Traffic  landing  requirements  are  derived  from  an  assessment  of 
current  aircraft  movements  in  the  control  zone  as  well  as  the 
planning  for  future  takeoffs  and  landings  at  airfields.  Up  to  300 
aircraft  are  to  be  accommodated,  distributed  over  10  airbases. 

While  the  sub-functions  are  described  in  terms  of  ATALARS  performing 
all  of  the  scheduling,  most  probably  it  will  be  a  cooperative  effort 
between  ATALARS  and  the  airfields. 

6 . 3  ,  1 .  1 . 1  Schedule  Planning 

The  planning  for  traffic  landing  requirements  assesses  the 
expected  future  aircraft  activity  in  the  control  zone  and  its 
capability  to  handle  the  traffic  load.  The  process  is  initiated  by 
a  periodic  review  of  flight  plan  data.  The  pertinent  data  is 

provided  by  interfaces  to  the  TAOS  (TACC  and  WOCs)  as  well  as  data 
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from  the  airfields.  The  data  is  keyed  to  the  ID  to  be  given  by  the 
aircraft  on  entering  ATALARS  airspace,  and  includes  routing 
information,  length  of  flight,  destination,  mission  number  and 
priority.  The  ATALARS  must  be  capab'Je  of  handling  the  frequency  of 
changes  occurring  in  the  control  zone  and  the  expected  volume  of  air 
traffic.  The  system  database  requirements  include  aircraft 
characteris tics ,  basing  requirements  (i.e.,  primary  and  alternate 
bases),  and  weather  forecasts.  Outputs  are  used  for  projecting 
landing  requirements  (number  of  aircraft,  runway  assignment,  and 
arrival  times)  at  airfields  within  the  control  zone. 

6 . 3 .  1 .  1 . 2  Current  Scheduling 

Current  scheduling  relates  to  the  real  time  air  traffic 
situation  in  the  control  zone.  The  process  starts  with  a  request 
from  the  airbase  selection  function  in  approach  control.  This  may 
be  a  routine  request  for  a  landing  time  slot,  a  result  of  overload 
in  the  number  of  aircraft  in  the  stack,  or  an  immediate  request  for 
landing  due  to  aircraft  damage  or  crew  injury.  The  input  to  the 
control  system  will  be  from  aircraft  automated  digital  data  or  a 
voice  communications  request  from  the  pilot.  The  . nput  contains  the 
aircraft  position  (latitude,  longitude,  altitude),  vector,  type  of 
aircraft,  fuel  remaining,  and  any  damage  report.  The  ATALARS  must 
be  capable  of  processing  immediate  requests  for  landing  emergencies 
and  handle  the  expected  air  traffic  density  of  70-100  aircraft  per 
hour.  Pertinent  database  information  is  derived  from  other  system 
functions  and  includes  current  weather  conditions  and  airfield 
status.  The  output  will  be  used  to  assign  time  slots  for  each 
aircraft  by  arrival  time  and  runway  assignment. 

6 . 3  . 1 . 2  Takeoff  Requirements  Assessment 

Assessment  of  takeoff  traffic  requirements  involves  current 
aircraft  awaiting  takeoff  and  aircraft  filing  flight  plans  at 
airfields  in  the  control  zone.  Up  to  10  bases  may  be  included  in 
various  ATALARS  control  areas.  As  with  scheduling  landings,  takeoff 
scheduling  will  probably  be  a  cooperative  effort  between  ATALARS  and 
the  airfields . 

6 . 3  .  1 . 2 .  1  Schedule  Planning 

The  planning  for  aircraft  takeoffs  includes  an  assessment  of 
future  air  activity  in  the  control  zone  and  its  capability  to  handle 
the  expected  additional  air  traffic  as  a  result  of  takeoffs.  The 
process  is  initiated  by  a  review  of  flight  plan  database 
information.  The  flight  plan  will  include  the  requested  departure 
time,  routing  information ,  priority,  and  type  of  aircraft.  The 
flight  plan  is  assigned  a  specific  identity  which  is  passed  to  the 
airspace  management  function.  The  database  reguir emunLs  include 
minimum  runway  length  for  aircraft  type,  aircraft  spacing  for 
takeoffs,  weather  forecasts,  enemy  activity,  and  the  air  defense 
situation.  The  ATALARS  must  be  capable  of  handling  Lhe  volume  of 
planned  takeoff  traffic  data.  Outputs  are  used  to  establish  time 
slots  for  departing  aircraft  and  runway  assignments. 
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6 . 3 . 1 . 2 . 2  Current  Scheduling 


Current  scheduling  requires  an  assessment  of  the  real  time  air 
traffic  situation  in  the  control  zone.  The  process  is  initiated  by 
a  request  for  takeoff  instructions  from  ground  traffic  control.  The 
ATALARS  will  review  the  flight  plans  for  current  scheduled  takeoffs 
within  a  specified  time  period.  By  reviewing  the  departure  times, 
runway  assignment/requiremenl,  type  of  aircraft,  priority,  current 
weather  conditions,  and  air  defense  environment,  the  function 
assigns  a  time  slot  and  runway  for  the  requesting  aircraft. 

63.1.3  Current  Airbase  Capabilities  and  Status  Assessment 

This  function  assesses  the  current  condition  of  up  to  10 
airbases  with  respect  to  their  capacity  for  aircraft  landings  and 
takeoffs  as  a  function  of  time.  Ihe  assessment  is  based  on  airfield 
status  data  provided  by  the  airfield  status  monitoring  function  and 
standard  operating  procedures  given  the  conditions  (e.g.,  runway 
width,  weather).  The  output  consists  of  defining  landing  and 
takeoff  intervals . 

6.3. 1.4  Time  Slots  Establishment 


This  function  establishes  the  order  of  landings  and  takeoffs  at 
airbases  in  an  A  f A  LARS  control  zone.  The  process  is  used  for 
planning  air  traffic  activity  or  is  initiated  by  a  situation  change 
requiring  establishment  of  more  time  slots  or  different  time 
assignments.  Inputs  corne  from  other  functions  such  as  landing 
requirements  assessment,  takeoff  requirements  assessment,  and 
current  airbase  capabilities/status  assessment.  Database 
requirements  must  include  fuel  consumption  rates  per  aircraft  type, 
separation  distance  between  aircraft,  and  weather  conditions.  The 
process  results  in  establishing  landing/takeof f  slots  to  be  used  in 
the  landing  control  and  departure  control  functions.  This  function 
initially  produces  a  plan  (schedule  of  time  periods  for  landings, 
takeoffs  or  both)  for  the  next  operations  cycle  and  then  adjusts  the 
plan  as  required. 

6 . 3 . 1 . 5  Assign  Time  Slots 

This  function  assigns  specific  time  slots  for  aircraft  awaiting 
landing  or  takeoff  instructions  at  airfields  in  the  ATALARS  control 
zone.  The  function  is  initiated  by  a  landing  request,  airbase 
selection,  or  takeoff  request.  Inputs  for  this  function  are  the 
available  time  slots  for  each  request.  Database  requirements 
include  separation  distance  between  aircraft,  weather  conditions, 
and  runway  conditions .  Outputs  go  to  notify  the  controller  for 
stack  extraction  and  aircraft  takeoff  through  the  landing  control 
and  departure  control  functions. 
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6.3.2  Airfield  Status  Monitoring 


This  function  determines  and  maintains  the  status  of  airfields 
within  the  control  zone.  It  is.  used  in  planning  traffic  scheduling 
and  air  traffic  control.  (See  Figure  6-7) 

6 . 3 . 2 .  1  Control  Systems 

This  process  monitors  the  operational  status  of  various  airfield 
systems  (landing  system,  ATC  tower,  air/ground  communications,  air 
defenses,  etc.).  The  process  is  initiated  by  a  notification  of 
change  in  status  for  one  or  more  of  the  systems.  Inputs  include 
periodic  reports  which  identify  the  system  and  its  operational 
status;  exception  reports  which  identify  the  system,  reason  it  is 
not  operational,  and  projected  outage  time;  and  return  to  operation 
reports  which  identify  the  system  and  the  restoral  time.  AfALARS 
must  accommodate  a  relatively  small  volume  of  data  and  expected 
frequency  of  changes.  The  database  will  identify  each  control 
system  and  its  current  operational  status  including  predicted 
restoral  times  for  any  non-operafional  systems.  Outputs  from  this 
function  are  used  to  assess  current  airbase  capabiliti.es/status  and 
issue  advisories  to  '.local  air  traffic  and  the  airspace  management 
function . 


6 . 3 . 2 . 2  Runways 

This  function  monitors  the  operational  status  of  all  runways 
(i.e.,  weather,  barriers,  cables,  etc.)  at  airfields  within  the 
control  zone.  The  process  is  initiated  by  a  notification  of  change 
in  operational  status.  Inputs  include  periodic  reports  which 
identify  the  airfi eld/runway  and  its  status;  exception  reports  which 
identify  non-operational  airfields/runways,  the  reason  (aircraft 
accident,  enemy  action),  and  the  projected  out  of  service  time;  and 
return  to  service  reports  which  identify  the  airfield  runway  and 
time  returned  to  service.  The  information  is  provided  from 
automated  digital  data  or  manual  inputs.  The  function  must 
accommodate  a  relatively  small  volume  of  data  and  expected  frequency 
of  changes.  The  database  requirements  include  the  identity  of 
runways/autobahns  and  their  status  or  forecasted  status  changes. 
Outputs,  changes  in  runway  status,  are  provided  to  the  traffic 
scheduling,  airbase  selection,  and  landing  control  functions.  This 
function  must  operate  in  real-time  to  react  to  runway  outages  (e.g., 
crash,  sabotage)  as  aircraft  are  approaching. 


6 . 3 . 2 . 3  Taxiway s 


This  function  monitors  the  operational  status  of  taxiways  at 
airfields  in  the  control  zone.  It  is  initiated  by  a  change  in 
status  notification.  Three  types  of  input  reports  will  be 
accommodated:  periodic,  exception,  and  return  to  service.  All 

reports  will  identify  the  taxiway.  The  exception  report  will 
provide  the  reason  it  is  not  operational  (i.e.,  enemy  action, 
congestion)  and  its  projected  out.  of  service  time.  The  return  to 
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service  report  will  also  provide  the  restored  service  time.  The 
system  must  handle  a  relatively  small  volume  of  data  and  expected 
frequency  of  changes.  The  database  requirements  include  an 
identification  of  taxiways  and  their  status  or  forecasted  status 
change.  Outputs  are  used  to  issue  notifications  to  the  traffic 
scheduling,  departure  traffic  control,  and  ground  traffic  control 
functions . 

6 . 3 . 2 . 4  Support  Facilities 

This  process  monitors  the  status  of  airfield  support  facilities 
(fuel,  ordnance,  maintenance  and  fire  control  equipment).  It  is 
initiated  by  a  notification  of  change  in  status  or  by  a  periodic 
review  of  support  capabilities.  The  inputs  include  fuel 
availability,  maintenance  capabilities  for  aircraft  type,  types  of 
ordnance  available,  and  status  of  emergency  equipment.  The  function 
must  have  the  storage  capacity  of  data  for  10  airbases,  as  well  as 
handle  the  expected  frequency  of  changes.  The  database  requirements 
include  the  current  and  predicted  changes  to  fuel  and  ordnance 
availability,  and  maintenance  capabilities  (i.e.,  .lack  of  spare 
parts,  personnel).  Outputs  are  used  to  support  the  airbase 
selection  function  through  notification  of  changes. 

6 . 3 . 2 . B  Issue  Advisories 

This  function  issues  advisories  to  aircraft  and  other  ATALAR8 
functions  on  the  current  status  or  changes  to  airfield  capabilities 
in  the  control  zone.  It  is  started  by  a  change  in  status  from  the 
monitoring  of  control  systems,  runways,  taxiways,  and  support 
facilities.  Outputs  are  a  periodic  notification  of  airfield  status 
to  aircraft  and  to  the  traffic  scheduling  and  airbase  selection 
functions.  This  information  will  be  transmitted  when  requested  by 
another  function  or  action. 

6.3.3  Monitor  F^tterns 


This  function  monitors  aircraft  after  takeoff  or  after  stack 
extraction  until  handoff  to  airspace  management  or  landing  control. 

6 . 3 . 3 . 1  Aircraft  Tracking 

This  function  establishes  and  maintains  track  of  70-100  aircraft 
per  hour  leaving  stack  operations  control  or  entering  the  airspace 
management  system  from  departure  control.  The  process  is  started  by 
notification  from  the  stack  extraction  or  departure  control 
functions.  Inputs  include  track  identification,  speed,  vector,  and 
runway  selection  for  landing  aircraft  and  the  flight  plan  for 
departing  aircraft.  The  database  .  jst  include  track  information  on 
all  aircraft  .in  the  control  zone  and  updated  flight  plan  data  for 
departing  aircraft.  Outputs  provide  the  current  aircraft  location 
to  the  approach  control  and  airspace  management  functions, 
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6. 3. 3. 2 


Detec  tlon/ftssessrnent 


This  function  detects  air  traffic  which  are  not  following 
directed  routings  in  the  area  of  stacks  and  airfields,  and  provides 
an  assessment  of  their  .impact  on  airspace  management  in  the  control 
zone.  The  process  is  initiated  by  detection  of  a  deviation  from 
aircraft  tracking  and  assesses  changes  required  to  avert  collision 
with  other  aircraft.  Inputs  include  a  detection  of  aircraft 
following  too  close,  incorrect  altitude,  aircraft  in  the  wrong 
corridor,  aircraft  crash  on  takeoff  or  landing  which  blocks  the 
runway,  and  unidentified  aircraft  in  the  monitor  pattern  area.  The 
database  includes  track  information  for  inbound  aircraft  and  flight 
profiles  for  takeoffs.  Outputs  will  alert  the  controller  and  pilot, 
as  applicable,  of  the  emergency  or  deviation. 

6.3.4  Monitor  Ground  Traffic 

This  function  establishes  and  maintains  the  locations  of  all 
ground  aircraft  and  vehicles  on  runways  and  taxiways. 

6 . 3 . 4 . 1  Runways 

This  function  monitors  the  location  of  all  aircraft  and  ground 
vehicles  on  runways.  Periodic  reviews  are  made  of  vehicle/aircraf t 
locations  and  any  requests  to  cross  runways,  The  process  includes 
vehicle/aircraft  identification  and  location.  Runway  identifi¬ 
cations,  ground  vehicle  (fuel  or  crash  truck),  and  taxiing  aircraft 
identifications  are  required  for  the  database.  Outputs  are  used  to 
notify  the  landing  control,  departure  control,  and  ground  traffic 
control  functions. 

6 . 3 . 4 . 2  Taxiways 

This  function  monitors  the  location  of  all  aircraft  and  ground 
vehicles  on  taxiways.  Periodic  reviews  are  made  of  vehicle/aircraf t 
locations.  The  process  includes  the  identification  of  taxiing 
aircraft  and  ground  vehicles  (fuel,  maintenance)  using  the 
taxiways.  Taxiway  identifications,  ground  vehicle  identification, 
and  taxiing  aircraft  identification  are  required  for  the  database. 
Outputs  are  used  to  notify  ground  traffic  control. 

6.3.5  Landing  Control 

This  function  contains  requirements  for  controlling  aircraft 
handoff,  landing  sequencing,  aircraft  guidance,  and  emergency 
response . 

6 . 3 . 5 . 1  Aircraft  Handoff 

When  an  aircraft  enters  the  final  landing  approach  window,  the 
landing  handoff  function  will  confirm  aircraft  intentions/ 
capabilities  along  with  airbase  activity  and  runway  status.  The 
aircraft  is  then  put  into  a  landing  queue  which  includes  all 
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aircraft  in  final  approach.  If  more  than  one  aircraft  is  found  to 
be  within  the  final  approach  window,  the  landing  sequencing  function 
is  flagged,  otherwise  the  process  is  passed  to  the  runway  control 
function . 

6 . 3 . 5 . 2  Landing  Sequencing  and  Spacing 

The  landing  sequencing  function  will  prioritize  the  landing 
queue  for  any  aircraft  with  conflicting  approaches.  This 
prioritization  will  be  based  on  the  aircraft's  status  and  location. 
The  process  is  then  passed  to  runway  control  for  coordination.  It 
also  fine-tunes  the  spacing  of  approaching  aircraft. 

6 . 3 . 5 . 3  Aircraft  Guidance 

The  landing  guidance  function  initially  provides  the  aircraft 
with  the  final  approach  clearance.  Ct  then  provides  guidance  to  the 
landing  gate  defined  by  the  landing  system  in  use  (e.g,,  MLS). 

(Note  that  the  landing  gate  could  be  visual  acquisition  of  the 
runway  or  airstrip  by  the  pilot.)  The  landing  guidance  precision 
must  be  in  accordance  with  the  landing  gate  requirements .  Thus, 
ATALAR3  must  meet  the  most  stringent  requirements  imposed  by  the 
absence  of  any  landing  guidance  system  at  the  airfield  itself.  The 
limitation  on  this  requirement  will  be  the  precision  with  which  the 
aircraft  can  determine  its  own  position,  altitude,  and  velocity. 

6 . 3 . 5 . 4  Emergency  Response 

Emergencies  occurring  during  final  approach  will  require 
responses  as  stated  in  6. 2. 4. 6.  Aircraft  which  are  unable  to  land 
will  be  re-entered  into  the  landing  procedure  through  the  stack 
operations  control  function. 

6.3.6  Departure  Control 

An  aircraft  requesting  departure  clearance  will  have  that 
request  passed  to  the  departure  control  function.  This  function 
confirms  aircraft  capabilities,  runway  status,  and  assigned  takeoff 
slot.  Then  it  is  entered  into  the  departure  queue  which  contains 
all  aircraft  requesting  departure  clearance.  If  more  than  one 
aircraft  requests  departure  clearance  at  the  same  time,  the 
departure  sequencing  function  is  activated;  otherwise,  the  process 
is  passed  to  the  runway  control  function  which  will  issue  takeoff 
clearance . 

The  departure  sequencing  function  will  prioritize  the  departure 
queue  for  all  aircraft  awaiting  departure  clearance.  This 
priorit!  zation  will  be  based  on  the  t'irne  the  clearance  was 
requested,  the  aircraft's  status,  and  assigned  time  slot. 

Assignment  or  reassignment  of  time  slots  may  be  required.  The 
process  is  then  passed  to  runway  control  for  coordination  which  will 
issue  takeoff  clearances. 
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After  takeoff  guidance  may  be  provided  to  ensure  a  safe 
transition  into  ATALARS  airspace.  Information  such  as  the 
aircraft's  capabilities,  status  and  flight  plan  in  addition  to 
current  local  air  activity  are  taken  into  account  in  determining  the 
pattern  to  be  followed  by  the  departing  aircraft.  Control  is  then 
passed  to  the  aircraft  routing  function  of  airspace  management  to 
provide  for  the  aircraft's  control  through  the  remaining  ATALARS 
airspace . 

6 . 3 . 7  Ground  Traffic  Control 

This  function  includes  control  of  aircraft  and  ground  vehicle 
movements  on  runways,  taxiways,  and  emergency  response. 

6 . 3 . 7 .  1  Runway  Control 


Runway  activity  must  be  controlled  at  a  central,  point  due  to  the 
requirement  to  service  landing  as  well  as  departing  aircraft.  This 
function  follows  the  landing  or  departure  handoff  after  any 
sequencing  required  to  keep  the  associated  landing  or  departing 
queue  updated.  Once  engaged,  the  runway  control  function  will 
allocate  runway  time  according  to  assigned  time  slots.  This 
function  will  also  consider  the  runway  status,  current  weather 
conditions,  and  the  status  of  the  aircraft  in  determining  the  amount 
of  runway  time  required  for  each  landing  or  departure  activity. 
Consequently,  the  runway  control  function  will  provide  information 
on  the  allotted  runway  availability.  The  runway  control  function 
will  then  issue  a  landing  or  takeoff  clearance  to  the  landing  or 
departure  guidance  function  to  safely  land  'he  aircraft  or  allow  the 
aircraft  to  depart. 

6 . 3 . 7 . 2  Taxi  Control 

This  function  controls  the  traffic  flow  for  both  aircraft  and 
ground  vehicles.  It  allows  flights  to  enter  and  depart  the  runway 
area  in  an  efficient  manner  and  provides  the  appropriate  control 
instruction.  For  landing  aircraft,  the  taxi  control  function 
allocates  room  to  allow  the  aircraft  to  reach  its  docking  position 
once  it  has  landed  and  ATALARS  control  is  no  longer  necessary.  This 
function  also  monitors  the  status  of  the  aircraft  and  servicing 
capabilities  of  the  base  or  airfield  to  provide  effective 
coordination  between  the  two.  For  departing  aircraft,  once  the 
aircraft  has  requested  departure  clearance,  this  function  must 
coordinate  with  runway  control  to  establish  the  runway  and  time  slot 
allocated  to  that  aircraft.  The  aircraft  is  then  entered  into  the 
traffic  flow  and  monitored  up  to  entry  into  the  appropriate  runway 
area  where  control  is  passed  to  the  runway  control  function  to  await 
takeoff  clearance. 

6 . 3 . 7 . 3  Emergency  Response 

Emergencies  occurring  during  ground  traffic  control  will  require 
responses  as  stated  in  6. 2. 4. 6. 
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6.4  EXERCISE/TRAINING 


The  ATALARS  concept  is  a  deviation  from  the  current  methods  of 
providing  ATC.  Further,  while  more  automation  is  to  be  expected  in 
the  future  for  both  civilian  and  military  ATC,  the  ATALARS  will  most 
probably  remain  a  variation  from  the  peacetime  norm  with  fully 
operational  ATC  systems.  Thus,  fairly  extensive  training  of 
operators  will  be  required.  To  a  more  limited  extent  training 
exercises  involving  pilots,  airbase  personnel,  and  operators  of 
interfacing  control  systems  are  also  necessary.  Thus,  like  all 
tactical  systems,  the  ATALARS  will  be  deployed  and  exercised. 

The  ATALARS  is,  however,  a  wartime  system,  primarily  intended  to 
provide  the  minimum  necessary  degree  of  control.  This  concept  may 
not  be  compatible  with  peacetime  requirements  for  control.  Thus, 
peacetime  operations  may  require  the  ATALARS  to  perform  additional 
functions  and  will  potentially  require  significant  differences  in 
its  external  interfaces  to  civilian  ATC  and  range  control  systems  as 
compared  to  wartime  external  interfaces. 

Substantial  analysis  of  this  aspect  of  the  ATALARS  is  not  a 
requirement  of  this  study.  A  cursory  examination  of  this  issue 
suggests  that  there  will  be  a  planning  function  similar  to  that 
described  in  Section  6.1.1,  but  with  some  differences  due  to  more 
rigid  peacetime  exercise  planning  requirements  and  flight  safety 
consideration.  There  will  be  a  requirement  for  interfacing  with 
range  control  in  addition  to  tactical  systems.  This  interface  will 
involve  flight  safety  coordination,  possibly  more  extensive  exchange 
of  track  data,  and  probably  a  more  formalized  and  complex  handoff 
process.  Similarly,  there  may  be  more  stringent  requirements  placed 
on  interfacing  with  a  civilian  ATC  (e.g.,  the  civil  corridor  over 
the  Eglin  AFB  range),  although  range  control  may  be  able  to  perform 
this  function  rather  than  having  the  ATALARS  do  so.  This  interface 
would  involve  handoff  of  military  aircraft  entering  the  exercise 
area  and  possible  exchange  of  planning  data  as  well  as  track  data. 

Some  comparatively  standard  functions  that  might  also  be 
included  in  the  ADP  system  to  support  exercise/training  are  data 
collection  and  simulation.  Data  could  be  automatically  collected, 
stored,  and  processed  to  provide  for  post  exercise  evaluation  and 
event  reconstruction .  Simulations  could  be  used  for  operator 
training,  to  supplement  exercise  activity  (e.g.,  increase  traffic 
density),  and  to  modify  the  exercise  environment  (e.g.,  weather). 
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SECTION  7.0 

SYSTEM  DESIGN  CONCEPTS 


The  previous  section  discussed  the  ATALARS  in  terms  of 
operational  system  functions,  i.e.  in  terms  of  what  the  combination 
of  personnel,  communications,  and  ADP  must  do.  Uery  limited 
consideration  was  given  to  allocation  of  tasks  between  man  and 
machine.  The  subsystems  were  not  yet  defined  except  perhaps 
implicitly,  and  interface  requirements  were  not  aggregated.  This 
section  begins  the  process  of  defining  the  ATALARS  as  a  system, 
rather  than  an  operational  entity. 

Section  4  of  ESD-TR-86-2B9  provided  an  overview  of  the  ATALARS 
concept  in  terms  of  six  subsystems:  indirect  surveillance, 
automated  ground  management  and  control,  automated  control  data  and 
information  transfer,  landing  guidance,  aircraft  on  board  ATC,  and 
interface  with  tactical  systems .  This  particular  decomposition  of 
the  ATALARS  combines  the  definition  of  system  functions  with 
subsystem  allocations,  e.g.,  the  control  function  (developing  and 
issuing  direction  to  aircraft)  is  split  between  automated  ground 
management  and  control  and  aircraft  on  board  ATC.  For  the  purpose 
of  establishing  and  maintaining  a  structured  approach  to  the  design 
of  the  ATALARS,  the  operational  functions  have  been  aggregated  and 
allocated  to  a  series  of  design  functions  which  can  in  turn  be 
further  decomposed  and  allocated  to  the  various  subsystems. 

The  ATALARS  definitely  consists  of  at  least  two  subsystems:  an 
ATALARS  van  and  an  aircraft  subsystem.  Less  definitely,  there  may 
be  an  airbase  subsystem  (involving,  for  example,  some  means  of 
monitoring  runways)  and  possibly  an  external  interface  subsystem 
(for  example  a  communications  terminal  to  be  deployed  to  the  local 
airbase  air  defense  system) .  These  latter  two  subsystems  will 
remain  comparatively  ill-defined  until  detailed  design  trade-offs 
are  conducted  and  acquisition  strategies  are  developed  which  take 
into  consideration  related  on-going  programs  (e.g.,  would  a  GPS 
terminal  required  for  relative  navigations  be  considered  part  of  the 
ATALARS?) . 

The  following  subsections  discuss  the  ATALARS  van  subsystem,  the 
aircraft  subsystem,  the  airbase  subsystem,  and  other  interfaces. 
Section  8  presents  design  considerations  (e.g.,  mobility, 
survivability,  security,  capacity,  and  ADP). 

7.1  UAN  SUBSYSTEM 

The  ATALARS  van  subsystem  will  mainly  consist  of  an  automation 
element  with  interfaces  to  external  subsystems  and  the  controller. 
The  automation  element  will  provide  the  database,  information 
processing,  and  appropriate  decision  making  support  to  conduct  the 
ATC  mission.  To  meet  this  requirement  it  is  necessary  to  ensure 
maximum  benefit  from  both  hardware  and  software  relative  to  system 
performance  as  well  as  system  functions.  The  automation  element 
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will  automate  the  ATALARS  surveillance ,  situation  monitoring  and 
assessment,  air  traffic  control,  ground  traffic  control,  landing 
control,  departure  control,  and  planning  functions. 

7.1.1  Automation  Element 


Hardware  is  the  key  to  the  systems'  ultimate  abilities.  It  is 
therefore  important  to  choose  components  whose  architecture  portrays 
the  same  attributes  that  the  automation  element  must  possess.  Use 
of  multitasking  will  reduce  idle  time  in  the  central  processing  unit 
and  more  effectively  mimic  human  processing  by  concurrently  working 
several  tasks  (in  small  increments).  Input  and  output  devices  must 
act  not  only  to  translate  information  between  man  and  machine,  but 
they  must  do  so  in  consonance  with  the  capabilities  of  the  ATALARS 
controller.  The  emphasis  here  lies  colely  with  the  ability  to 
display  this  information  to  the  cor-  roller  (or  pilot) ,  allowing  the 
human  to  make  the  decisions.  Providing  data  that  can  be  interpreted 
accurately  and  quickly  is  essential,  including  the  ability  to  allow 
data  to  be  presented  in  various  formats,  but  always  differentiating 
between  the  types  of  data.  The  ability  to  simultaneously  display  a 
combiniation  of  different  information  clearly  on  one  display /monitor 
will  allow  one  controller  to  perform/rnonitor  many  functions.  One 
method  of  handling  the  large  volume  of  information  would  be  to 
present  only  initial  data  and  controls  unless  additional  information 
is  requested.  Control  support  of  recommended  options  can  queue  the 
controller  to  reduce  reaction  time  and  increase  confidence  in  the 
actions  that  need  to  be  taken. 

7  . 1 .  1 . 1  Software 

As  hardware  dictates  the  ultimate  abilities  of  the  system,  the 
software  determines  how  well  the  system  works.  Concurrent 
programming  (having  several  programs  in  execution  at  a  given  time) 
is  the  first  concept  employed  to  make  the  construction  of  an  ATALARS 
automation  system  feasible.  By  moving  the  various  activities  of  an 
operating  system  into  asychronous  processes,  only  the  mechanisms  for 
interprocess  communication  and  time  sharing  are  allocated  to  a 
fundamental  operating  system  kernel.  The  kernel  gives  each  process 
the  appearance  of  having  control  of  all  processing  capabilities 
which  can  be  accessed  through  that  kernel,  These  virtual  processing 
units  allow  many  programs  to  be  executed  at  a  single  instant.  These 
systems  are  called  open  systems  when  Lhey  deal  with  large  quantities 
of  diverse  information  within  massive  concurrency. 

Another  characteristic  of  open  systems  is  asynchrony.  Since  the 
system  cannot  predict  the  behavior  of  its  environment,  new 
information  can  enter  the  system  at  any  time  requiring  it  l:o  operate 
asynchronously  with  that  environment.  Due  to  their  physical 
distance,  components  of  the  system  would  have  to  be  slowed  to  the 
lowest  common  denominator  in  order  to  maintain  synchronization,  so 
these  too  must  operate  asynchronously  to  achieve  real -time 
performance.  Decentralized  control  is  required  to  keep  decisions 
close  to  where  they  are  needed  in  order  to  avoid  confusion  created 
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by  an  inability  to  maintain  a  current  status  on  the  entire  system. 
This  is  due  to  the  asynchronous  behavior  of  the  communications  and 
the  inherent  unreliability  and  bottleneck  characteristics  of  using  a 
single  controlling  devices.  The  components  of  an  open  system  may 
have  their  internal  operation,  organization  or  current  state 
unavailable  to  other  components  because  of  security  reasons  or 
communications  outages.  Information  should  be  transferred  between 
components  via  explicit  communications  to  maintain  security, 
conserve  energy,  and  ensure  the  integrity  of  each  component.  These 
explicit  communications  allow  each  component  to  track  its  own  state 
and  interfaces  and  allows  detection  and  identification  of  downed 
systems.  The  failure  of  any  component  must  be  accomodated  by  other 
operating  components  to  allow  the  system  to  operate  continuously. 

7 . 1 . 1 . 2  Database 

The  data  requirements  of  an  AT  A  LARS  system  will  be  very  large, 
and  the  architecture  on  which  this  database  is  structured  should 
enhance  an  ability  to  access  the  data  quickly.  Such  an  architecture 
might  be  based  on  a  relational  model,  that  is,  data  is  stored  and 
accessed  by  means  of  a  two-dimensional  table  where  data  can  be 
traced  by  its  relation  to  other  data  in  the  table.  Network  or 
tree-based  structures  can  also  be  used  but  these  may  prove  to  be  too 
limited  for  an  ATALARS  .implementation.  Measures  to  ensure  the 
validity  of  the  data  such  as  making  use  of  a  replicated  database 
should  be  employed  to  support  fault-tolerance  within  the  processing 
system. 

7  . 1 . 1 .  3  Operational  Code 

The  operational  software  should  be  approached  by  ensuring  a 
strict  adherence  to  standards,  employing  a  top  down,  traceable 
design,  and  allowing  functional  partitioning.  Attributes  to  be 
gained  by  use  of  a  functionally  distributed  design  include  improved 
performance  (in  reduced  response  times),  increased  flexibi'lty, 
maintainability,  reliability,  and  an  adaptability  for  incremental 
enhancements.  The  top  down  design  should  address  a  hierarchical 
decomposition  of  activities  to  subactivities,  to  specific  tasks,  in 
order  to  support  a  system  response  based  on  event  clustering, 
efficiently  determining  machine  aiding  requirements ,  and  allowing 
establishment  of  effective  decomposition  tools. 

The  nature  of  air  traffic  control  requires  expert  knowledge  on 
the  part  of  the  controller  to  quickly  interpret  vast  amounts  of  data 
and  immediately  apply  them  in  a  real-time,  real  world  environment. 

As  the  amount  and  types  of  information  available  to  the  controller 
increases,  it  becomes  extremely  critical  what  tasks  are  allocated  to 
maximize  the  controller's  effectiveness.  In  designing  the 
automation  system  to  perform  those  tasks,  concepts  of  expert  system 
technology  are  applied  to  the  performance  of  highly  specialized 
tasks  normally  considered  to  require  human  expertise.  By  providing 
the  system  with  highly  detailed  knowledge  of  the  rules  of  air 
traffic  control,  the  system  can  apply  that  knowledge  without  the 
consult  of  a  human  operator. 
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7.1.2  Surveillance 


From  Section  6.0  it  is  clear  that  the  ATALARS  must  establish  and 
maintain  a  track  on  aircraft  in  the  assigned  airspace.  While 
precision  requirements  vary  between  the  operational  functions  (e.g., 
flight  following  an  aircraft  in  a  transit  corridor  as  opposed  to 
providing  landing  guidance),  other  requirements  are  fundamentally 
the  same  (i..e.,  the  need  for  position,  altitude,  velocity, 
identification,  and  associated  flight  plan  data).  Thus,  the  ATALARS 
surveillance  function  may  be  considered  the  aggregate  of  the 
tracking  functions.  Also  included  is  the  initial  appending  of 
flight  plan  data  and  the  rnaintainance  of  any  changes  to  that  data  as 
introduced  by  other  ATALARS  functions  or  other  controlling 
authorities . 

Since  the  surveillance  function  is  a  passive  activity  which 
monitors  and  correlates  positional  data  received  from  external 
sources,  much  of  this  activity  will  consist  of  managing  that 
database . 

7 .  1 . 2 . 1  Track  Data 

In  the  ATALARS  concept,  there  are  two  sources  of  track  related 
data:  reports  from  the  aircraft  and  reports  from  external 

surveillance  systems  (air  defense  radars,  AWAC.S ,  TAGS  radars).  In 
both  cases  the  interface  will  consist  of  a  data  link  and  voice 
communications . 

To  provide  the  basic  track  data  (position,  altitude,  and 
velocity)  the  aircraft  subsystem  (See  Section  7.2)  must  periodically 
and  automatically  transmit  its  knowledge,  derived  from  on-board 
systems,  to  the  ATALARS  van.  Thus,  the  aircraft  subsystem  must 
provide  readouts  from  the  appropriate  avionics  (e.g.,  GPS,  MLS,  IfJS, 
altimeter)  in  a  format  suitable  for  automatic  transmission  (e.g., 
via  JTIDS) . 

The  van  subsystem  must  be  able  to  accept  and  automatically 
process  data  from  both  sources,  correlate  as  required,  and  produce  a 
displayable,  geographic  track  database  for  use  by  either  man  or 
machine  in  performing  functions  requiring  track  data.  Tracks 
(position,  velocity)  must  be  updated  periodically  with  frequency  of 
update  based  either  on  the  most  stringent  requirement  (landing 
guidance)  or  the  requirement  imposed  by  the  activity  of  the 
aircraft.  A  track  prediction  algorithm  may  be  required  to 
compensate  for  terrain  masking. 

The  aircraft  ID  must  be  associated  with  the  track.  Position 
data  provided  by  the  aircraft  subsystem  will  include  ID;  however, 
external  sources  will  have  "U/I"  (unidentified)  and  "enemy" 
designations  as  well  as  friendly  ID.  Most  probably,  the  tracking 
function  will,  on  updating  the  tracks,  also  check  for  course  and 
velocity  deviations  as  well  as  potential  collisions. 
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The  tracking  function  must  also  handle  tracks  outside  the 
ATALARS  airspace,  since  automatic  transmissions  will  be  received  by 
the  van  even  if  the  aircraft  is  outside  the  airspace.  Similarly, 
data  from  external  sources  may  include  both  irrelevant  and  relevant 
(impending  handoff)  tracks  outside  the  airspace. 

Also,  it  is  conceivable  that  there  may  be  aircraft  in  the 
ATALARS  airspace  for  which  the  ATALARS  should  not  provide  any 
guidance  (e.g.,  interceptors).  These  tracks  must  be  flagged  to 
avoid  providing  any  automated  guidance. 

7 . 1 . 2 . 2  Ancillary  Data 

In  order  to  allow  automation  of  some  of  the  more  routine  ATC 
functions,  the  ATALARS  must  be  aware  of  the  intent  of  the  aircraft 
(i.e.,  the  flight  plan).  Thus,  as  a  track  is  established  and 
maintained,  the  system  must  also  establish  and  maintain  the 
associated  ancillary  data:  intended  course,  speed,  altitude,  and 
destination.  The  surveillance  function  must  append  this  data  to  the 
track  data  as  a  track  is  established.  As  changes  a~e  made  due  to 
pilot  decisions,  ATALARS  guidance  or  other  factors  of  this  data  must 
be  updated. 

7 . 1 . 3  Situation  Monitoring  And  Assessemnt 

The  three  primary  mission  functions  all  require  varying  degrees 
of  status/situation  monitoring  to  assess  the  impact  on  air 
operations.  The  environment  to  be  monitored  includes  weather,  enemy 
activity,  friendly  air  defenses,  interfacing  systems,  airbases,  and 
air  traffic  related  factors  (e.g.,  density,  delays).  This  system 
function  would  aggregate  the  requirements  of  all  three  functions, 
maintaining  the  distinction  between  these  requirements;  for  example, 
weather  data  for  airspace  management  as  opposed  to  airfield  traffic 
control . 

The  function  must  produce  and  update  a  displayable,  geographic 
situation  database.  Access  to  the  database  (either  direct  or  in 
terms  of  a  display)  must  allow  separation  or  aggregation  of  the 
various  environmental  factors  as  well  as  varying  levels  of  detail 
(e.g.,  the  airfield  traffic  control  function  must  consider  wind 
shear  situations  on  runway  approaches,  while  the  airspace  management 
function  only  requires  a  generalized  weather  situation) . 

The  function  must  identify  generally  adverse  situations  (e.g., 
thunderstorm,  enemy  activity)  and  issue  appropriate  advisories  as 
well  as  identifying  more  specific  and  immediate  emergency  situations 
(e.g.,  a  crash  on  a  runway  when  other  aircraft  are  approaching  or 
loss  of  a  landing  control  system) . 

In  view  of  the  need  to  minimize  the  manual  workload  within  the 
van,  much  of  the  data  to  be  processed  by  this  function  to  establish 
and  maintain  the  database  must  be  provided  via  data  link. 

Similarly,  the  system  must  be  capable  of  automatically  generating 
and  disseminating  advisory  information. 
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7.1.4  Control  of  Air  Traffic 


This  system  function  aggregates  the  various  control  and  control 
related  mission  functions:  internal  and  external  handoffs,  general 
(e.g.,  corridor  utilization)  and  specific  (e.g.,  stack  extraction, 
spacing,  sequencing)  guidance,  and  emergency  response.  The  ATALARS 
concept  calls  for  three  versions  of  control:  automated  issuance  of 
guidance  information  using  knowledge-based  techniques,  pilot 
decisions  based  on  information  provided  by  the  ATALARS,  and  ground 
controller  guidance.  Further,  each  of  the  three  primary  operational 
functions  requires  a  different  degree  of  control  in  terms  of 
precision.  In  addition,  the  ATALARS  concept  fundamentally  calls  for 
control  by  exception.  Guidance  is  provided  only  to  the  extent 
necessitated  by  deviation  from  plans  or  emergency  situations. 

7 . 1 . 4 . 1  Handoffs 

To  a  certain  degree  handoffs  can  be  implicit  and  automated.  As 
an  example,  as  an  aircraft  enters  the  ATALARS  airspace,  the  system 
can  automatically  flag  the  track  for  ATALARS  control  and  issue  a 
message,  to  be  acknowledged  by  the  aircraft,  establishing  the 
ATALARS  as  the  control  authority.  The  process  would  be  reversed  on 
exiting  the  airspace.  Similarly  internal  handoffs  to  establish  a 
different  or  more  precise  mode  of  control  can  also  be  handled 
automatically  by  modifying  the  track  flag.  Thus,  a  transmitting 
aircraft  following  a  pre-established  corridor  or  flight  plan  may 
never  interact  with  the  ATALARS  van  except  for  the  "handshake"  on 
entry,  exit,  takeoff,  or  landing. 

7 . 1 . 4 . 2  Emergency  Response 

Emergency  control  requirements  can  be  differentiated  from  normal 
control  requirements  in  terms  of  available  (required)  response  time 
(e.g.,  seconds  for  collision  avoidance  versus  longer  time  frames  for 
providing  instructions  to  assure  proper  sequencing  and  spacing  for 
landing) .  Due  to  the  expected  degree  of  automation  involved  in  the 
control  function,  the  ground  controller  may  not  be  "in  the  loop"  as 
an  emergency  situation  requiring  immediate  reaction  arises.  To 
orovide  him  data,  allow  him  to  assess  the  situation,  and  issue 
instructions  may  take  too  long.  Thus,  the  system  must  provide  for 
automated  generation  of  instructions  to  the  pilot  (e.g.,  veer  left) 
while  simultaneously  notifying  the  ground  controller.  Less  time 
sensitive  emergencies  (e.g,,  fuel  shortage)  would  be  brought  to  the 
attention  of  the  ground  controller,  if  the  system  could  not 
automatically  provide  one  or  more  recommended  courses  of  action  to 
the  pilot. 

7 . 1 . 4 . 3  Normal  Control 

Normal  control  will  be  a  combination  of  pilot/controller 
interaction  and  knowledge  based  autornated/semi-autornated  support. 
Aircraft  which  are  not  following  a  pre-planned  route  or  cannot  do  so 
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will  most  probably  require  controller  support  using  uoice 
communications  to  establish  the  situation,  select  a  course  of 
action,  and  define  an  appropriate  flight  path.  To  a  limited  extent, 
the  system  could  be  designed  to  allow  the  pilot  to  digitally  query 
the  ADP  system  in  the  van  and  receive  appropriate  guidance  or 
optional  courses  of  action  (e.g.,  nearest  usable  landing  strip). 

The  bulk  of  the  comparatively  routine  control  requirements  can  be 
met  by  a  knouiledge-based  system  presenting  information  to  the  pilot. 

The  knowledge-based  system  must  be  capable  of  differentiation 
between  mandatory  control  instructions  (e.g.,  on  landing  approach), 
discretionary  instructions  (e.g.,  entry  into  a  landing  pattern  in 
low  density  traffic  under  UFR  conditions),  and  generalized 
instructions  (e.g,,  corridor  utilization  rules).  Further,  it  must 
allow  for  pilot  or  controller  override  with  appropriate  follow-up. 

7.1.5  Control  of  Ground  Traffic 

The  extent  to  which  the  ATALARS  must  exercise  control  over 
ground  traffic  (aircraft  and  ground  vehicles)  at  an  airfield  is,  at 
this  point,  a  fuzzy  area.  Clearly,  if  the  ATALARS  is  to  take  over 
all  ATC  tower  functions  in  the  event  of  the  destruction  of  the  tower 
and/or  RSU,  control  of  ground  traffic  is  included.  However,  since 
ground  vehicles  will  not  likely  have  digital  communications  and 
manpower  in  the  van  will  be  limited,  control  for  multiple  airfields 
from  the  van  may  not  be  feasible.  Most  probably,  this  function 
would  have  to  be  apportioned  between  the  van  and  alternative/back-up 
systems  at  the  airfield  which  may  or  may  not  be  part  of  the 
ATALARS.  Procedural  "work-arounds"  may  also  be  employed. 

7.1.6  Landing  Control 

Conceptually,  the  landing  function  is  simple:  it  schedules 
landing  and  provides  guidance  to  the  aircraft  to  a  landing  gate 
determined  by  aircraft  and  airfield  capabilities  (e.g.,  MLS,  visual 
acquisition  of  the  runway) .  Actual  implementation  is  somewhat  more 
complex . 


The  system  must  determine  the  landing  gate  for  the  particular 
aircraf t/airf ie'ld  combination  based  on  the  data  provided  by  the 
situation  monitoring  functions.  Scheduling  is  also  affected  by 
various  environmental  factors,  aircraft  status,  and  runway 
utilization  (e.g.,  takeoff  schedules).  Provisions  must  also  be  made 
for  missed  approaches  and  emergency  situations  (e.g.,  wheels  up). 
Thus,  automation  of  this  function  will  require  a  combination  of 
techniques  and  access  to  a  substantial  database  with  both  static 
(e.g.,  MLS  characteristics )  and  dynamic  (e.g.,  weather)  components. 

7.1.7  Departure  Control 


Departure  control  is  potentially  the  simplest  system  function  in 
that  much  of  the  "control"  is  pre-planned  (e.g.,  departure  flight 
path).  Departure  control  is  fundamentally  a  scheduling  function 
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with  transmission  of  a  "go"  signal  after  an  environmental  status 
check  (e.g.,  is  the  runway  clear?)  just  prior  to  the  scheduled 
takeoff.  Two  "hand-shakes"  are  required:  readiness  for  takeoff  and 
takeoff . 

The  scheduling  itself  would  be  at  three  levels.  The  first 
(performed  by  the  planning  function)  would  provide  takeoff  slots. 

The  second,  performed  by  this  function,  would  assign  slots  on 
request  by  the  airbase  shortly  before  the  aircraft  are  ready.  The 
final  would  be  the  assignment/reassignment  as  the  aircraft  indicates 
readiness.  To  minimize  the  manual  workload  in  the  van, 
communications  with  the  airbase  and  with  the  aircraft  would  require 
data  links . 

7.1.8  Planning 

Potentially  the  most  manpower  intensive  function  is  the 
aggregation  of  the  planning  functions:  the  overall  planning  and 
plan  adjustment  of  the  airspace  management  function,  route  selection 
from  the  approach  control  function,  and  scheduling  <rrom  the  airfield 
traffic  control  function.  While  a  large  amount  of  automation  and 
automated  support  can  be  provided  ( particularly  to  routing  and 
scheduling),  much  of  the  data  may  not  be  available  in  machine 
processable  form.  Current  and  planned  efforts  to  automate,  at  least 
partially,  some  aspects  of  air  operations  planning  (e.g.,  the  use  of 
a  Computer  Automated  Force  Management  Systems  (CAFMS)  for  ATO 
generation)  will  alleviate  the  situation  (while  probably  aggravating 
interoperability  issues). 

7 . 1 . 9  Exercise/Traininq 

See  Section  6.4. 

7.2  AIRCRAFT  SUBSYSTEM 

The  ATALARS  will  interface  with  airborne  aircraft  and  aircraft 
preparing  for  takeoff.  While  on  the  ground,  the  interface  will  be 
used  for  pilot/controller  communications  and  to  automatically 
identify  the  aircraft  and  its  location  on  a  runway/taxiway .  While 
airborne,  the  interface  will  be  used  for  pilot/ATALARS 
communications  in  passing  control  instructions,  providing  position 
information,  advising  the  pilot  of  current  airfield  conditions,  and 
notifying  the  controller  of  critical  aircraft  conditions  (i.e., 
emergency  fuel  level,  aircraft  damage,  crew  injury).  Prior  to 
takeoff  or  entry  into  an  ATALARS  control  zone,  some  basic 
information  (flight  plans,  fuel  consumption  rate  and  fuel  capacity 
by  aircraft  type)  will  have  been  entered  into  the  database. 

The  J1  IDS  or  similar  system  will  be  used  as  the  ,-rimary  method 
of  data  transfer  through  this  interface.  While  the  aircraft  is  on 
the  ground  the  controller  may  also  use  manual  data  inputs.  Air/ 
ground  voice  radio  communications  will  be  used  as  an  alternate 
method  for  information  transfer. 
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The  aircraft  interface  has  a  two  fold  purpose:  first,  to  prouide 
aircraft  data  to  the  ATALARS  uan/controller ,  and  secondly  to  prouide 
communications  between  the  uan/controller  and  the  aircraf t/pilot . 

The  first  can  be  considered  the  downlink  interface  and  is  used  to 
prouide  aircraft  position  and  status  information  as  well  as  pilot 
entered  data  to  the  ATALARS  uan/controller.  The  second  can  be 
considered  the  uplink  interface  and  is  to  be  used  by  the  uan/ 
controller  for  prouiding  instructions/information  to  the  pilot  or 
for  requesting  specific  '.information  from  the  ATALARS  aircraft 
terminal . 


Figures  7--1  and  7~2  depict  two  functional  configuration  designs 
for  the  aircraft  interface.  Both  of  these  designs  assume  a  JTIDS  or 
compatible  terminal  in  the  aircraft.  The  first  uses  the  JTIDS 
terminal  interface  with  the  aircraft  data  bus  to  prouide  all 
required  aircraft  status  information  to  the  ATALARS  terminal.  This 
will  also  require  aircraft  status  information  to  be  prouided  to  the 
ATALARS  terminal.  This  will  require  some  modification  to  the  JTIDS 
terminal  for  the  transfer  of  aircraft  status  data  to  the  ATALARS 
interface.  Data  will  transuerse  this  interface  for  communications 
between  the  ATALARS  aircraft  terminal  and  the  ATALARS  uan.  The 
second  design  requires  the  direct  connection  of  the  ATALARS  terminal 
to  the  aircraft  data  bus.  The  second  design  will  result  in  a 
simpler  interface  between  the  JTIDS  and  ATALARS  aircraft  terminals 
by  requiring  less  of  a  modification  to  the  JTIDS  terminal. 

As  a  minimum,  the  ATALARS  aircraft  terminal  will  consist  of  a 
Digital  Data  Processor  (DDP),  Pilot  Data  Input  Deuice,  Display 
Monitor,  and  a  JTIDS  Interface.  The  DDP  will  accomplish  the 
automated  collection  of  aircraft  status  information  (either  through 
the  JTIDS  interface  or  a  direct  data  bus  interface),  do  the 
necessary  data  processing  for  dissemination  to  the  downlink 
interface,  process/disseminate  data  receiued  from  the  uplink 
interface,  process  data  entered  by  the  pilot,  and  display 
appropriate  information  on  the  pilot's  monitor.  Data  messages  will 
be  coded  for  transmission  through  the  JTIDS  terminal  and  may  include 
aircraft  track  number,  aircraft  identification  code,  aircraft  system 
status,  and  position  information.  The  pilot's  monitor  which  could 
include  a  heads-up  display  will  prouide  weather,  controller 
instructions,  aduisories,  and  emergency  information.  The  DDP 
software  design  should  include  a  pilot  acknowledgement  routine  for 
critical  instructions/aduisories .  After  initial  "hand-shaking" 
between  the  ATALARS  uan  and  aircraft  terminal,  the  aircraft  terminal 
will  automatically  prouide  periodic  updates  on  its  position  through 
the  use  of  the  GPS.  Prior  to  takeoff,  the  flight  plan  will  be 
entered  in  the  DDP  for  reference  and  will  be  updated  as  necessary. 
The  design  of  the  ATALARS  aircraft  terminal  must  carefully  consider 
the  limited  space  auailable  in  the  aircraft.  Of  particular  concern 
will  be  the  size  of  the  display  monitor. 

The  ATALARS  will  rely  on  the  JTIDS  uoice  capability  for  uoice 
communications  between  the  pilot  and  controller.  The  HAUE  QUICK 
radio  will  be  used  as  secondary  mode  for  uoice  communications . 
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FIGURE  7-1 

AIRCRAFT  FUNCTIONAL  CONFIGURATION  1 
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FIGURE  7-2 

AIRCRAFT  FUNCTIONAL  CONFIGURATION  2 


7.3  AIRBASE  SUBSYSTEM 


Exclusive  of  communications  interfaces  with  the  airbase,  the 
ATALARS  may  be  required  to  provide  (deploy)  equipment  to  each 
airfield  it  will  support  to  assist  in  the  performance  of  two 
functions:  accurate  positioning  of  the  aircraft  relative  to  the 

runway  and  monitoring  of  runway/taxiway  conditions. 

7 . 3 . 1  Aircraft  Positioning 

In  the  absence  of  a  landing  system  such  as  MLS,  the  ATALARS  must 
provide  accurate  landing  guidance  to  aircraft.  MI.S  normally 
provides  ICAO  Category  II  capability  (100  feet  decision  height)  and 
can  provide  (for  specially  configured  aircraft)  ICAO  Category  III 
capability  (no  decision  height  minimum).  The  GPS  precise 
positioning  service  (PPS)  is  expected  to  provide  15  meter  spherical 
error  probability  (SEP)  accuracy  .  Thus,  if  the  runway  location  is 
known  to  the  same  accuracy  (using  a  portable  GPS  receiver) , 

MLS-type  capability  cannot  be  provided. 

GPS  can  also  be  used  in  a  differential  mode  (relative  to  a  GPS 
receiver  at  a  known  ground  reference  point)  to  provide  submeter 
accuracies.  Achieving  these  accuracies  in  a  real-time  mode  requires 
RF  transmission  f rom  the  receiver  site.  Thus  a  transceiver  would 
have  to  be  deployed  to  a  known  position  relative  to  the  runway  to 
achieve  the  positioning  accuracy  necessary  to  provide  adverse 
weather  landing  guidance. 

7.3.2  Runway/Taxiway  Monitoring 

From  a  functional  perspective,  the  requirements  for  runway  and 
taxiway  monitoring  are  simple.  The  design  of  a  readily  deployable, 
reliable  sensing  system  capable  of  virtually  all-weather  operation 
is,  however,  less  readily  definable.  Functionally,  the  sensing 
system  must  provide  ceiling,  visibility,  surface  condition,  and 
usage  status.  Manual  observation  and  reporting  of  the  first  three 
combined  with  accurate  positioning  data  for  aircraft  on  the  ground 
(using  the  GPS  differential  navigation  mode)  is  one  possible 
solution.  More  sophisticated  sensing  systems  for  usage  data  which 
would  cover  ground  vehicles  as  well  as  aircraft  are  probably 
required  for  adverse  weather  operations.  (See  Section  8.0) 

7.4  COMMUNICATIONS  INTERFACES 

7.4.1  Tactical  Air  Control  System  (TAGS) 

The  ATALARS  management  unit  will  interface  with  TAGS  elements 
(e.g.,  CRC,AWACS)  under  which  the  Al'C  function  is  subordinate  and/or 
has  mutual  airspace  coverage  responsibility ,  The  interface  will  be 
accomplished  through  the  TACS  air  and  ground  data  communications 
networks.  The  TACS  provides  planning,  direction,  and  control  of 
tactical  air  operations.  The  ground  TACS  that  will  be  fielded  prior 
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to  the  year  2000  is  known  as  the  Modular  Control  Element  (MCE).  The 
MCE  may  be  deployed  to  form  a  complete  system  or  deployed 
incrementally  (CRC,  Control  and  Reporting  Post,  Forward  Air  Control 
Post)  to  augment  an  existing  fixed  or  mobile  control  system.  The 
basic  system  module  of  the  MCE  is  the  AN/TYQ-23  Operations  Module 
(OM)  which  provides  overall  airspace  management  from  a  ground  based 
system.  It  may  operate  independently  or  in  conjunction  with  other 
related  systems  such  as  the  AWACS,  FIQ  TAP,  TACC,  and  an  Army/Air 
Force  air  defense  system.  The  OM  is  expected  to  be  fielded  using 
the  TADl'L-A  and  TADIL-B  message  formats  through  a  JTIDS  equipment 
interface  for  data  transfer  with  the  airborne  TACS  elements  such  as 
AWACS  and  for  airbase  defense  systems.  The  AWACS  will  use  the  new 
TADIL-J  message  format  when  communicating  within  the  TACS  nets  or 
with  JTIDS  equipped  aircraft.  Like  the  OM,  the  ATALARS  van  will 
communicate  with  these  systems  to  obtain  aircraft  tracking 
information.  To  minimize  the  extent  of  ATALARS  software  design,  a 
single  message  exchange  format  should  be  specified.  It  is  expected 
that  in  the  post-2000  time  period  the  standard  message  format  will 
be  TADIL-J;  with  all  operational  systems  using  this  format. 
Therefore,  ATALARS  should  be  designed  using  the  TADIL-J  format  for 
message  exchange  (or  another  format  which  is  being  widely  used  by 
tactical  systems  in  the  ATALARS  fielded  time  frames).  Modifications 
to  other  systems  may  be  required  to  meet  this  standard  message 
format  or  a  special  interface  provided  in  the  ATALARS  to  accommodate 
other  message  formats. 

After  initial  deployment  of  an  ATALARS  and  communications 
connectivity  has  been  established,  the  TACS  interface  with  ground 
systems  such  as  the  OM  or  the  AWACS  must  be  sized  to  accommodate  the 
volume  of  message  transfer.  This  may  become  of  particular  concern 
when  an  ATALARS  has  ATC  responsibility  for  several  airfields  with 
heavy  traffic  volume.  The  minimum  data  rate  for  this  interface 
should  be  16Kb/s. 

7.4,2  Air  Defense  Systems 

ATALARS  will  interface  with  Air  Force  and  Army  air  defense 
elements  protecting  the  runways  at  airfields/airbases  in  the  combat 
area.  The  ATALARS  van  operation  with  these  air  defense  systems  will 
be  similar  to  that  of  other  TACS  elements.  ATALARS  will  provide 
flight  planning  information  and  the  air  defense  systems  will  provide 
tracking  information  as  well  as  identify  friendly  air  corridors  for 
ATC  operations.  This  interface  will  be  established  using  a 
dedicated  radio  link  or  cable  connection  when  the  systems  are 
colocated.  Current  interfaces  with  air  defense  systems  operate  at 
600/1200/2400  bps  and  use  the  TADIL-B  message  format.  Although  no 
new  programs  to  replace  or  change  the  air  defense  system  have  been 
identified,  it  is  expected  that  this  will  occur  and  will  allow  the 
use  of  the  standard  JTIDS  data  message  format  (TADIL-J)  in  the  post- 
2000  time  period.  As  with  the  TACS  interface,  some  special 
accommodations  may  be  required  for  systems  which  have  not  converted 
to  the  TADIL-J  format.  A  heavy  volume  of  information  transfer 
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should  be  expected  through  this  interface  to  provide  current  updates 
to  the  databases  of  both  the  ATALARS  and  air  defense  systems.  Data 
rates  of  16Kb/s  or  more  should  be  expected  for  this  interface. 

7.4.3  Airbase 

The  ATALARS  van  will  have  direct  data  connections  to  up  to  10 
nearby  airbases  for  ATC  coordination  and  planning.  A  single 
interface  may  be  provided  for  each  airbase  to  provide  connectivity 
to  the  ATC  tower,  base/wing  command  center,  and  local  weather 
information.  The  on-base  connections  will  be  made  through  the 
existing  base  communications  network  or  tactical  communications 
elements . 

The  volume  of  data  provided  by  the  airbase  will  change  as 
conditions  of  the  airfield  are  affected  by  weather,  control  systems 
status,  takeoffs/landings,  and  runway  availability.  Several 
dedicated  radio  links  (including  relays)  will  be  required  to  provide 
the  data  connectivity  for  multiple  airbases.  Cable  interfaces  will 
also  be  necessary  to  allow  connection  of  colocated  facilities.  It 
may  be  possible  to  minimize  the  additional  communications  facilities 
by  direct  connection  to  the  closest  TRI-TAC  communications  network 
interface.  A  low  data  rate  (4800  bps  or  less)  is  expected  for  each 
airbase  connection.  Interfaces  at  the  airbase  need  to  be  specified 
including  the  message  formats.  Terminal  devices  may  be  required  at 
the  base/wing  command  centers  and  ATC  towers  to  enter  information  or 
receive  requests  from  the  ATALARS  van/controller .  Sensors  could  be 
connected  to  either  terminals  for  data  transfer  of  weather 
information  and  control  system  status.  Figure  7-3  depicts  a  typical 
deployment  of  an  ATALARS  van  with  multi-airfield  responsibility. 
Distances  between  relay  points  would  be  10-15  miles  allowing  the  use 
of  millimeter  wave  radios.  The  number  of  sensors  would  vary  by 
location  depending  on  other  data  available  at  the  base  command 
center.  Uoice  communications  would  be  used  as  an  alternate  means  of 
providing  data  to  the  ATALARS  controllers. 

7.4.4  Weather  Service 

In  addition  to  the  airbase  interface,  weather  forecasts  and 
local  conditions  will  be  provided  through  an  interface  with  the 
Tactical  Automated  Weather  Distribution  System  at  nearby  airfields/ 
airbases.  The  weather  information  will  be  provided  through  a 
dedicated  digital  data  link.  A  capability  for  manual  inputs  via  the 
airbase  interface  will  provide  an  alternate  method  of  entering  local 
weather  conditions/observations . 

7.4.5  Inter-ATALARS 

An  interface  will  be  provided  to  permit  the  exchange  of  ATC 
information  among  adjacent  ATALARS.  Figure  7-3  includes  a  depiction 
of  two  ATALARS  serving  several  airbases.  Connection  of  the  systems 
would  be  via  one  or  more  millimeter  wave  radio  links.  Each  ATALARS 
van  database  would  store  appropriate  information  on  several  airbases 
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to  allow  transfer  of  control  In  case  of  equipment  failure  and/or 
other  emergencies  at  one  of  the  monitored  locations.  Millimeter 
waue  radio  links  would  also  be  used  for  connection  of  the  adjacent 
ATALARS  units  and  a  maximum  data  rate  of  64Kb/s  should  be  expected. 
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SECTION  8.0 
DESIGN  CONSIDERATIONS 


The  previous  two  sections  defined  what  an  ATALARS  must  be 
capable  of  doing  and  what  must  be  designed.  This  section  discusses 
considerations  in  developing  that  design.  The  ATALARS  design  will 
be  driven  by  numeric  requirements  (e.g.,  the  number  of  aircraft 
simultaneously  in  the  assigned  airspace),  operational  considerations 
(e.g.,  pilot  workload),  environmental  considerations  (e.g.,  variance 
in  aircraft  avionics  suites),  near  term  technology  (e.g.,  JTIDS, 

GPS,  or  similar  systems),  and  other  factors. 

8.1  GENERAL  CONSIDERATIONS 

Like  all  tactical  systems,  ATALARS  must  be  designed  to  be 
survivable  in  a  high  intensity,  conventional  conflict  where 
extensive  use  of  electronic  combat  is  involved.  Thus,  the  basic 
concept  discribed  in  ESD-TR-86-259  calls  for  mobility,  indirect  (no 
radar  emissions)  surveillance,  and  secure  anti-jam  (AJ) 
communications . 

8.1.1  Mobility 

Despite  the  use  of  indirect  surveillance  and  frequency  hopping 
communications,  the  ATALARS  van  will  emanate  sufficient  radiation  in 
the  frequency  bands  to  be  readily  detectable  and  locatable.  Thus, 
for  survivability  reasons  alone  the  van  must  be  mobile.  (Note  that 
since  it  will  not  be  near  the  PEBA/FLOT,  it  will  not  be  as  readily 
targetable)  Unless  a  "leap-frog"  concept  is  employed  with  one  van 
in  operation  while  a  second  is  being  redeployed,  the  ATALARS  must 
remain  in  operation  while  in  motion. 

In  addition,  since  JTIDS  and  HAUE  QUICK  (or  similar  systems)  are 
line-of-sight  systems,  deployment  locations  must  be  based  on  terrain 
masking  considerations.  Thus,  the  van  must  be  capable  of  rough 
cross-country  travel  to  assure  its  deployment  at  a  suitable  location 
and  operation  while  in  motion. 

In  effect,  the  requirement  is  for  a  self-propelled,  self- 
contained  vehicle.  This  places  a  premium  on  weight,  space,  and 
power.  It  also  implies  a  degree  of  redundancy,  if,  as  suggested  in 
ESD-TR-86-259 ,  remote  communications  vehicles  are  employed. 

Clearly,  cost  benefit  analyses  must  be  conducted  to  evaluate 
single  versus  multi-vehicle  designs  and  "leap-frogging"  versus 
in-motion  operation. 

8.1.2  Security 

In  general,  the  interface  options  discussed  later  in  this 
section  provide  adequate  security  (encryption,  low  probability  of 
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intercept  (LPI)).  Since  ATALARS  is  not  the  primary  or  only  user  of 
either  the  data  (e.g.,  ATO)  or  communications  media  (e.g.,  JTIDS), 
ATALARS  requirements  will  not  be  a  driver  with  respect  to  the 
security  issue.  In  effect,  the  security  of  aircraft  or  TAGS 
communications  will  be  upgraded,  if  necessary,  and  ATALARS  will  be 
forced  to  be  compatible. 

If,  as  suggested  in  ESD-TR-86-259 ,  remote  communications 
vehicles  are  used  by  ATALARS,  LPI  and  encryption  considerations 
become  a  factor  in  intra-ATALARS  communications.  The  use  of 
millimeter  wave  radios  (highly  directional  antennas)  and 
fiber-optics  cables  (both  suggested  in  ESD--TR-  86-259)  may  be 
precluded  by  the  mobility  requirement.  They  are  absolutely 
precluded  if  operation  while  in  motion  is  required.  If,  as 
expected,  the  TAGS  elements  become  more  mobile  as  well  as  physically 
and  functionally  dispersed,  data  and  voice  communications  used  by 
the  TACS  should  be  suitable  for  use  by  ATALARS. 

8.1.3  Survivability 

Both  of  the  above  discussions  relate  to  survivability  as  well. 
One  of  the  bases  for  the  mobility  requirement  is  survivability.  LPI 
communications  reduce  vulnerability  to  S1GINT  locating  systems. 
Electromagnetic  pulse  (EMP)  hardening  and  Chemical  Biological, 
Radiological  (CBR)  protection  are  standard  requirements  and  must  be 
incorporated ,  (Note  that  these  latter  requirements  are  often  waived 
in  order  to  use  off-the-shelf  (OTS)  or  Commercial  OTS  (COTS) 
equipment.  However,  ATALARS  is  expected  ho  operate  in  an 
environment  which  is  being  severely  degraded  due  to  conventional  and 
other  types  of  attacks.  Thus,  these  requirements  cannot  be 
waived,)  Hardening  against  conventional  ordnance  (e.g.,  kevlar 
blankets)  may  be  an  option  which  consumes  too  much  space  and/or  adds 
too  much  weight. 

Survivability  against  jamming  is  provided  by  A-J  features  of 
systems  such  as  JTIDS  and  HADE  QUICK.  However,  as  with  security, 
whatever  communications  systems  are  used  by  the  TACS  will  also  be 
used  by  the  ATALARS.  Thus,  the  TACS  requirements  and  the  resulting 
design  will  drive  ATALARS  communications. 

To  a  certain  extent,  the  above  statement  applies  to  the  ATALARS 
interfaces  with  the  airbases  as  well  However,  some  aspects  of  the 
interface  (e.g.,  for  runway  monitoring)  may  be  unique  to  ATALARS. 
Since  the  multi-base  nature  of  ATALARS  and  the  mobility  requirement 
preclude  the  use  of  cables  and  probably  highly  directional  systems, 
other  means  of  achieving  LPI/ A-J  are  required. 

8.1.4-  Coverage  and  Capacity 

Coverage  and  capacity  are  interrelated .  In  theory,  coverage 
provided  by  ATALARS  can  be  expanded  (using  relays),  until  the 
capacity  limits  are  reached.  In  practice,  coverage  limits  for 
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ATALARS  are  based  on  two  operational  factors:  geographic  dispersion 
of  the  airfield  to  be  serviced,  and  the  related  volume  of  airspace 
which  ATALARS  must  control  to  assure  safe  and  efficient  operations. 

At  a  minimum,  it  would  seorn  that  ATALARS  would  require  two  to 
three  minutes  of  coverage  of  returning  aircraft  in  order  to  provide 
any  room  at  all  for  sequencing  and  spacing  aircraft.  This  suggests 
a  20  to  30  nautical  mile  radius  zone  surrounding  the  airfield.  If 
spacing  between  airfields  is  considered,  the  zone  may  be  expanded  an 
additional  20  to  30  nautical  miles.  (This  assumes  that  ATALARS 
serves  a  geographically  concentrated  set  of  landing  strips, 
airfields,  and  airbases,  not  widely  separated  ones.)  Thus  ATALARS 
coverage  zones  would  be  on  the  order  of  50  to  100  nautical  miles 
maximum  dimension.  (Note  that  this  begins  to  present  line  of  sight 
problems  with  respect  to  low  flying  aircraft  and  possibly  with 
ATALARS/airbase  communications) . 

This  area  of  coverage,  in  a  scenario  such  as  the  NATO  Central 
Region,  can  involve  large  numbers  of  aircraft,  possibly  in  excess  of 
the  300  aircraft  specified  in  ESD-TR-86-259 .  However,  as  ATC 
facilities  are  reduced  by  enemy  attacks,  thus  requiring  the  use  of 
ATALARS,  the  number  of  aircraft  is  also  reduced  due  to  attrition. 

Again  considering  the  European  scenario  and  the  propensity  of 
tactical  air  operations  to  be  concentrated  at  particular  hours,  the 
combined  launch  or  recovery  rates  for  several  airfields  could  be 
substantial  over  a  short  time  period.  Aircraft  from  four  or  five 
squadrons  returning  to  bases  from  air  interdiction  missions  within 
an  hour  is  reasonable.  Adding  some  air  defense  activity,  a 
continuous  stream  of  close  air  support  missions,  and  a  few 
miscellaneous  missions,  ATALARS  could  be  required  to  support  up  to 
200  takeoffs  and  landings  in  an  hour  (approximately  two  flights  of 
four  aircraft  each,  every  two  minutes). 

Considering  the  ready  availability  of  memory  and  rapid 
processing  capability  of  today's  ADP  technology,  these  numbers  are 
not  constraining.  Even  one  second  track  updates  are  well  within  the 
capability  of  an  IBM  PC.  The  most  probable  constraining  factor  will 
be  the  degree  of  manual  involvement  in  the  takeoff  and  landing 
processes  and  the  number  of  simultaneous  (i.e.,  within  one  or  two 
minutes)  activities  involved.  One  emergency  and  several  flights  of 
aircraft  should,  however,  be  well  within  the  capacity  of  three  or 
four  ADP  supported  controllers. 

8.2  ADP  SYSTEM 

The  ADP  system  is  intended  to  automate  many  controller  functions 
as  well  as  to  decrease  controller  workload  for  the  remaining 
functions  by  providing  automated  support.  In  effect,  the  software 
will  be  an  expert  system  performing  certain  functions  and 
decision-aiding  others.  Thus,  there  are  two  types  of  design 
considerations:  maintaining  continuity  of  the  controller  functions, 
and  to  a  lesser  extent  maintaining  manual  review  and  override 
capability 
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In  addition,  the  ATALARS  concept  requires  it  to  assume  functions 
of  other  systems  as  these  systems  are  destroyed  by  enemy  action  or 
become  unusable  for  other  reasons.  Thus,  ATALARS  must  be  designed 
with  a  modularity  that  corresponds  to  the  functional  modularity  of 
the  systems  whose  functions  it  will  assume. 

8 . 2 . 1  Continuity  of  Functions 

Both  the  ADP  hardware  and  software  must  have  a  fail-safe 
capability.  More  specifically,  both  must  incorporate 
self-diagnostic  and  self-healing  features  that  prevent  abrupt 
termination  of  guidance  functions  and  provide  for  notifying  both 
controller  and  pilot  of  degradation  or  cessation  of  capabilities. 
This  notification  must  include  a  description  of  self-healing  action, 
recommended  action,  and/or  imposed  limitations  on  operations  that 
ensue  from  the  failure. 

8.2.2  Manual  Review  and  Override 

As  with  all  expert  systems,  it  is  doubtful  that  the  ATALARS 
software  can  be  designed  to  accommodate  all  contingencies.  Thus, 
ATALARS  must  provide  for  a  review  and  override  by  two  persons:  the 
pilot  and  the  controller.  In  the  event  of  override  by  one,  it  must 
notify  the  other,  possibly  with  recommendations  for  subsequent 
action  by  the  controller  if  the  pilot  overrides. 

Another  significant  requirement  is  the  necessity  for  the 
controller (s)  to  review  software  decisions  in  the  aggregate,  rather 
than  individually.  Review  of  each  guidance  instruction  developed  by 
the  software  would  not  significantly  reduce  controller  workload. 
Thus,  the  software  must  provide  an  overview  (e.g.,  of  corridor 
activity)  in  a  manner  which  allows  assessment  of  overall  viability 
of  software  directed  activity. 

A  final  significant  difference  between  the  ATALARS  and  current 
systems  is  its  real-tirne  nature.  Most  current  systems  speed  the 
decision  making  process  to  the  point  where  operator  review  of 
software  output  takes  less  time  than  manual  decision  making,  for 
ATALARS  this  may  not  be  true  under  certain  conditions  (e.g., 
collision  avoidance,  landing  guidance).  Thus,  extreme  care  must  be 
taken  in  the  design  to  avoid  elemental  review  processes  and  to 
provide  rapidly  assimilatable  presentation  of  data  for  decision 
review. 

8.2.3  functional  Modularity 

It  is  clear  that  the  ATALARS  cannot  be  allowed  to  operate  in  a 
manner  where  its  functions  overlap  other  system  functions  (e.g., 
providing  landing  guidance  when  MLS  is  in  use).  Thus,  each  function 
must  be  carefully  bounded  and  tailored  to  correspond  to  the 
functions  of  external  systems  so  that  enabling/disabling  of  these 
functions  maintains  a  non-overlapping  ATC  environment. 
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This  enabling/disabling  feature  of  ATALARS  functions  must  also 
accommodate  variability  in  the  environment  (e.g.,  allowing  the  use 
of  MLS  at  one  airfield  while  providing  landing  guidance  at 
another),  further,  in  some  cases,  the  design  must  provide  for 
disabling  only  the  output  dissemination  (e.g.,  issuing,  guidance) 
portion  of  the  function  because  ATALARS  cannot  assume  the  function 
or  perform  other  functions  if  continuity  is  not  maintained  (e.g., 

MLS  provides  landing  guidance,  but  ATALARS  must  monitor  and  control 
runway  usage) . 

8.2.4  Applicability  of  Off-the-Shelf  Hardware 

Current  16-bit  Uery  Large  Scale  Integrated  (ULSI)  circuit 
technology  can  support  the  multitasking  environment  and  may  prove 
adequate  for  the  ATALARS  application,  although  proven  32-bit 
technology  could  very  well  meet  a  post-2000  implementation. 

Timing  will  be  more  critical  than  ever  before  in  the  post-2000 
real-time  environment.  The  width  of  the  databus  will  affect  the 
speed  with  which  the  processor  can  "crunch"  numbers  and  evaluate 
decisions.  Currently,  32-bit  ULSI  circuit  technology  is  providing 
this  state-of-the-art  performance;  however,  it  will  be  important  to 
evaluate  the  microcode  support  available  to  insure  the  ATALARS 
processor  is  being  used  efficiently,  taking  maximum  benefit  of  the 
processing  speeu/performance . 

Data  storage  is  a  vital  element  of  the  ADP,  since  ATALARS  will 
receive  large  quantities  of  data  from  various  sources.  Immediate 
accessability  precludes  the  use  of  secondary  storage  devices  for 
much  of  this  data.  Dedicated  Read-Only-Memory  (ROM)  along  with  high 
speed  Random-Access-Memory  (RAM)  will  obviously  be  used.  For 
example.  Dynamic  RAM  (DRAM)  has  shown  its  usefulness  in  error 
detection  when  used  for  a  fault-tolerant  check  resulting  from  a 
Hamming  code  or  voting  scheme  to  ensure  the  accuracy  of  the  data. 

The  use  of  color  displays  enhances  the  controllers '  discretion 
in  identifying  and  manipulating  data.  Although  the  number  of  colors 
used  will  be  determined  from  a  human  engineering  standpoint,  the 
availability  of  colors  will  be  a  function  of  the  display  technology. 
Cathode  Ray  Tube  (CRT)  technology  provides  high  resolution, 
full-spectrum  color;  however,  its  space  requirements  may  prove 
undesirable.  New  plasma  and  LCD  technology  have  a  distinct 
advantage  in  that  they  may  be  applied  to  slim  profile,  flat  panel 
displays.  Currently,  color  applications  in  these  two  new 
technologies  are  limited;  however,  further  development  may  bring 
color  as  well  as  a  proven  track  record  to  allow  ATALARS  to  take 
advantage  of  the  flickerless,  distortionless  viewing;  small  size; 
low  weight  and  power;  low  maintenance;  and  high  reliability  of  these 
technologies . 

The  type  of  input  device  should  be  flexible  for  maximum  use  by 
the  controller.  Whether  it  is  an  interactive  touch  screen,  a 


digitizing  tablet,  a  light  pen,  a  trackball,  a  pushbutton,  or  a 
mouse,  the  automatic  system  should  not  hinder  the  controllers 
actions.  Some  alphanumeric  input  from  the  keyboard  will  probably  be. 
required;  however,  research  into  automated  voice  recognition  inputs 
could  prove  invaluable  i  *upport  of  real-time  updates  to  the 
ATALARS  database.  The  use  r  non-volative  magnetic  bubble  memory 
may  also  provide  the  high  o  o^ty  storage.  Its  ruggedness,  small 
size,  light  weight,  and  limited  power  dissipation  could  prove 
advantageous  to  the  ATALARS  design. 

8-2.5  Applicability  of  Off-the-Shelf  Software 

By  the  time  ATALARS  is  under  full  scale  engineering  development, 
it  is  highly  probable  that  some  of  the  ATALARS  functions  will  have 
been  automated  for  other  systems.  The  FAA  has  an  automated 
collision  avoidance  program  in  progress.  The  MCE  program  (See 
7.4.1)  is  automating  certain  ATC  (CRC,  CRP,  FACP)  functions  such  as 
surveillance,  track  correlation,  track/ATO  correlation,  and 
identification.  Higher  order  languages  such  as  C  or  Ada  are 
currently  being  used  in  real-time  operating  environments.  Further, 
current  DOD  regulations  require  Ada  to  be  used  as  the  higher  order 
language  for  all  software  procurements .  Thus,  it  is  highly  probable 
that  the  ATALARS  development  will  be  able  to  use  off-the-shelf 
software  as  a  basis  for  many  of  its  functions  making  use  of  Ada 
implementations . 

The  software  language  utilized  is  mostly  a  function  of 
maintainability  to  be  discussed  in  light  of  projected  capabilities. 
The  operating  requirements  of  ATALARS  are  not  expected  to  exceed 
these  types  of  environments.  The  use  of  specialized  languages  For 
data  manipulation  or  symbolic  computation  should  be  accessed  for 
their  flexibility  in  working  with  the  chosen  general-purpose 
language  as  well  as  providing  more  or  better  capabilities.  Current 
implementation  such  as  the  use  of  LISP  in  a  C-based  environment 
shows  potential  for  future  developments  to  take  advantage  of 
specific  capabilities/features  in  multiple  languages. 

8.3  EXTERNAL  INTERFACES 


As  with  the  planning  for  any  new  system,  interoperability  must 
be  considered  early  in  the  program  to  allow  an  orderly 
implementation  and  fielding  of  the  system.  Some  items  that  must  be 
considered  include:  the  time  period  for  system  fielding  (both  the 
initial  system  and  the  length  of  phase-in  time),  identification  of 
interfacing  systems/equipment  that  will  be  operational  during  the 
fielding  period,  other  interfacing  systems/equiprnenL  that  will  be 
implemented  shortly  after  system  fielding,  modifications  required  to 
other  systems/equipment  that  will  be  operational  during  the  fielding 
period  (to  include  minimum  operational  quantities  to  satisfy  mission 
requirements),  and  the  number  of  proposed  systems  that  will  be 
fielded.  External  interfaces  were  discussed  briefly  in  7.4  and  will 
be  included  in  design  considerations  of  this  section.  Because  of 
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the  limited  quantity  of  expected  production  systems,  the  fielding  of 
a  system  such  as  ATALARS)  should  not  require  extensive  modifications 
to  other  interfacing  systems  or  disrupt  the  capability  of  other 
systems  to  satisfy  their  primary  mission  requirements .  Careful 
consideration  should  be  given  to  operation  with  interfacing  systems. 

8.3.1  Airbase  Interface 

The  airbase  interface  actually  involves  several  subsystems  and 
interfaces.  These  are:  the  Lojjer  interface  (if  operational),  the 
ground  traffic  monitoring  subsystem  and  interface,  the  weather 
monitoring  interface,  tne  Weapons  Operations  Center  interface,  and 
the  landing  system  interface 

8 . 3 .  1 . 1  Tower  Interface 

If  the  tower  (including  RAPCON  and  RSU)  is  fully  or  even 
partially  operational,  the  interchange  of  data  between  the  ATALARS 
van  and  the  tower  is  minimal.  Further,  the  workload  within  the  van 
is  minimal  with  respect  to  operations  at  that  airbase.  Thus,  secure 
voice  communications  could  suffice  for  handoffs  and  the  occasional 
exchange  of  situation  and  status  data. 

However,  there  are  benefits  to  be  gained  from  a  digital 
interface  for  track  data  and  machine  processable  messages.  The 
handoff  process  is  surer  witn  less  chance  of  mis  correlating  tracks. 
Congestion  at  the  airfield  or  weather  changes  that  could  affect 
automated  ATALARS  sequencing  anc!  spacing  Functions  could  be  directly 
input  without  manual  intervention  in  the  ATALARS  van.  Further,  if 
tower  functions  are  only  partially  degraded,  data  from  ATALARS  may 
be  used  to  minimize  the  number  of  tower  functions  lost.  Voice 
communications  would  still  be  required  for  non-f ormatted  messages, 
emergencies,  anci  unique  situations. 

In  effect,  there  are  options  for  the  interface  with  the  tower. 

In  terms  of  increasing  complexity  and  cost  these  are:  secure  voice 
only,  secure  voice  and  a  data  entry  terminal  for  direct  input  of 
data  from  the  tower  to  ATALARS,  secure  voice  and  a  terminal  for  data 
entry  and  display  of  ATALARS  tracks,  and  secure  voice  and  a  fully 
integrated  ATC-  airbase  facility  subsystem  to  provide  for  exchange  of 
data  between  the  tower  and  ATALARS. 


The  last  ontion  is  incompatible  with  the  basic  premise  of 
ATALARS  (e.g.,  if  there  is  damage  to  the  tower  to  the  point  where 
ATALARS  mubt  take  over  some  function,  the  ATALARS  interface  would 
probably  also  bo  damaged).  The  other  three  options  should  be  the 
subject  of  a  cost-benefit  trade  study. 


8.3.1 .2  Ground  Traffic  Monitoring  Subsystem  and 
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If  tower  functions  (including  an  RSU)  are  sufficiently  degraded 
to  the  point  where  ATALARS  must  monitor  runway  and  taxdway  traffic. 
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ATALARS  requires  a  sensing  subsystem,  a  means,  preferably  automated, 
of  transmitting  the  information  to  the  van,  and  communications  for 
exercising  some  degree  of  control  over  the  traffic.  Traffic  control 
could  be  performed  by  airbase  personnel  and  relevant  information 
transmitted  to  the  van  via  voice.  However,  this  kind  of  inter. ace 
would  require  the  full  attention  of  one  controller  in  the  van, 
making  it  impractical  to  service  up  to  ten  airfields. 

There  are  a  number  of  sensor  options  which  require 
investigation.  Rudimentary  pattern  recognition  technology  could  be 
employed  with  imaging  sensors.  Magnetometers,  motion  sensors,  heat 
sensors,  and  others  are  also  possibilities.  Issues  relating  to  the 
use  of  sensors  include  numbers,  cost,  reliability,  false  alarm  rate, 
deployability,  and  data  transmission  options.  In  addition, 
consideration  needs  to  be  given  to  the  nature  of  the  reporting: 
absence  of  anything  to  be  sensed,  positive  data  indicating  arrival 
or  departure  from  the  runway  or  taxiway,  or  both.  The  technology, 
including  automated  processing,  has  been  available  since  the  late 
1960s.  Extensive  cost  reduction  efforts  were  undertaken  in  the 
early  1970s;  however,  current  state  of  the  art  and  associated  costs 
require  more  extensive  investigation  then  is  possible  under  the 
current  study  effort. 

8 . 3  . 1 .  3  Weather  Monitoring  Interface 

Weather,  as  it  relates  to  landings  and  takeoffs  (ceiling, 
visibility,  wind-shear),  requires  continuous  monitoring  only  in 
rapidly  changing  conditions  (e.g.,  thickening  fog,  approaching 
thunderstorm) .  Uoice  communications  would  seem  to  be  acceptable 
under  almost,  all  conditions  except  where  all  bases  serviced  by 
ATALARS  are  geographically  close  and  affected  by  the  same  rapidly 
changing  weather  pattern.  Even  under  these  conditions,  since  the 
probability  that  all  bases  are  simultaneously  very  active  is  low, 
voice  communications  should  not  overload  van  personnel.  Thus, 
maintaining  voice  communications  with  an  observer  should  suffice. 

8 . 3 . 1 . 4  Weapons  Operations  Center  (WOC)  Interface 

Planning  within  the  TAOS  and  its  overseas  analogues  is  becoming 
increasingly  automated.  ATALARS  will  require  a  direct  digital 
interface  with  whatever  system  is  in  use  at  the  WOC  to  develop  and 
maintain  the  more  detailed  flight  plans  produced  in  response  to  the 
ATO.  The  same  interface  could  be  used  to  exchange  additional 
information;  however,  this  would  probably  require  a  software 
modification  to  the  system  usc'i  by  the  WOC.  Such  an  interface  would 
allow  direct  data  entry  from  the  WOC  as  well  as  providing  the  WOC 
with  situation  data  from  the  ATALARS. 

8  .  3 .  1 . 5  Landing  Systems  Interface 


The  ATALARS  concept  presumes  operations  involving  a  landing 
system  (MLS  or  similar  system)  or,  in  its  absence,  the  use  of  a  GPS 


8. 3. 2. 2  Surueillance  and  Control  Interfaces 


It  is  currently  planned  to  replace  the  CRC,  Control  and 
Reporting  Post  (CRP),  FACP,  and  MPC,  with  the  MCE.  The  AWACS  and 
surface-to-air  defenses  such  as  the  HAWK  are  to  be  interfaced  with 
the  MCE.  Thus,  in  theory,  a  TADIL.-B  interface  to  an  MCE  would 
provide  the  necessary  external  surveillance  data  through  the  MCE 
surveillance  function.  This  interface  may  even  obviate  the 
necessity  for  track  correlation  within  the  ATALARS. 

Alternatively,  the  ATALARS  may  require  separate  interfaces  for 
surveillance  data  as  follows: 

1.  AWACS  ( JTIDS,  TADIL-A ) .  This  would  also  provide 
compatibility  with  the  Navy  Air  Tactical  Data  System  (AIDS) 
and  the  Naval  Tactical  Data  System  (NTDS) . 

2.  CRC,  CRP,  FACP,  and  MPC  or  the  MCE  equivalent  (TADIL-B)  This 
would  also  provide  compatibility  with  Army  Air  Defense 
Command  Posts  (AADCPs)  and  the  Marine  Tactical  Air  Operations 
Center  (TAOC) . 

Coordination  to  establish  the  specifics  of  procedures  for 
aircraft  transiting  airspace  boundaries  or  operating  in  overlapping 
control  zones  requires  voice  communications  between  ATALARS  and  the 
other  control  authority  (e.g.,  CRC).  Although  some  data  relevant  to 
those  procedures  may  require  entry  into  the  ATALARS  database,  it  is 
doubtful  that  all  required  communications  could  be  accomplished  via 
rigidly  formatted  messages. 

8 . 3 . 2 . 3  Air  Defenses 

The  ATALARS  will  require  interfaces  with  long  range  surface-to- 
air  defenses  (e.g.,  HAWK),  short  range  defenses  (e.g.,  at  the 
airbase  itself),  and  possibly  other  types  of  defenses  such  as 
jammers.  Currently,  TADIL-B  is  used  by  the  AADCP  and  the  Army 
Tactical  Data  Link  (ATDL-1)  by  HAWK  fire  units.  These  are  both 
automatic,  secure,  full-duplex,  point-to-point,  dedicated  links. 

The  first  would  provide  the  means  for  notifying  ATALARS  of  changes 
in  deployment,  corridors,  ROEs,  etc.  The  second  would  be  used  by 
ATALARS  to  notify  HAWK  fire  units  of  approaching  friendly  aircraft, 
if  necessary.  Uoice  or  data  link  could  be  used  for  coordination 
with  local  (airbase)  air  defenses,  since  they  would  not  normally 
operate  in  free  fire  modes  unless  the  airbase  is  under  attack, 

8.3.3  Weather 

Weather  information  (other  than  the  detailed  runway  related 
data)  is  available  indirectly  through  the  necessary  TACS  interfaces 
(HQ  TAF,  TACC,  WOC)  discussed  above.  Thus,  while  the  desirability 
of  direct  interfaces  with  AWS  systems  (e.g.,  the  Tactical  Automated 
Weather  Distribution  System)  is  unquestionable,  the  necessity  is  not 
unquestionable.  Specific  cost-benefit  analyses  which  need  to  be 
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performed  are  associated  with:  automated  direct  input  of  AWS  data  to 
the  ATALARS  database,  off-line  AWS  input  to  a  separate  terminal  and 
display,  and  relay  of  data  via  TACS  elements. 

8.3.4  Inter-ATALARS 

The  requirements  for  an  inter-ATALARS  interface  are 
fundamentally  the  same  as  for  other  surveillance  and  control 
interfaces.  Thus,  whatever  interface  is  used  for  exchange  of  track 
data  with  the  TACS  (e.g.,  TADIL-B)  can  also  be  used  to  do  the  same 
between  ATALARS  vans.  Voice  communications  will  be  required  to 
coordinate  responsibilities  and  procedures  at  airspace  boundaries. 
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SECTION  9.0 

PROGRAM  AND  FEASIBILITY  DEMONSTRATION  PLANNING 


9.1  INTRODUCTION 

Section  6.0  described  ATALARS  in  terms  of  its  primary  system 
functions  (airspace  management,  approach  control,  airfield  traffic 
control,  and  the  exercise/training  approach).  Figure  6-1 
illustrated  the  definition  of  the  first  three  in  terms  of  the  type 
of  aircraft  activity.  This  section  describes  recommended 
programmatic  events  for  the  completion  of  the  conceptual  phase  and 
provides  the  basis  for  an  initial  field  demonstration  and  subsequent 
procurement  activity  for  the  ATALARS  program.  For  purposes  of 
discussion  within  this  section,  various  program  phases  are 
identified  in  Figure  9-1  and  further  expanded  in  the  following 
paragraphs.  Preliminary  cost  estimates  for  Phase  I  and  II  are 
described  in  Appendix  C.  Phase  I  costs  are  estimated  at 
approximately  $1M  and  Phase  II  at  $10. 7M  to  11. 5M. 

Phase  0  is  currently  being  accomplished  under  a  Technical 
Engineering  Management  Support  (TEMS)  contract  through  HH  Aerospace 
Design,  Inc.  with  ARINC  Research  Corporation  and  Vanguard  Research 
Inc,  as  team  members.  The  Phase  1  effort  will  include  a  further 
analysis  directed  toward  the  Man-Machine  Interface  (MMI)  for  both 
the  aircraft  and  ground  applications  leading  to  a  feasibility 
demonstration  in  the  field,  Phase  II.  Currently,  the  feasibility 
demonstration  is  anticipated  to  include  three  contractors  for  the 
purpose  of  obtaining  different  designs.  Following  the  field 
demonstration,  a  contract  will  be  awarded  for  Full  Scale  Engineering 
Development  ( FSED) ,  Phase  III.  This  will  be  followed  by  an  expanded 
field  test,  Phase  IV,  which  would  be  used  to  check  out  the 
algorithms  developed  in  Phase  III.  After  a  certain  confidence  level 
has  been  reached  (e.g.,  safety  of  flight,  MMI),  the  Full  Scale 
Production  (FSP),  Phase  U,  contract  would  be  awarded.  This  section 
covers  the  milestones  and  requirements  leading  to,  but  not 
including,  the  FSED  effort, 

A  proposed  program  schedule  depicting  major  milestones  through 
the  award  of  the  FSED  contract  is  presented  in  Figure  9-2.  (Note: 
This  schedule  was  generated  using  the  assumption  that  program 
funding  is  available  for  each  program  phase  at  the  time  that  it  is 
required . ) 

9.2  PHASE  I  CONTRACTOR  TASKING  AND  PRODUCTS 

This  phase  includes  follow-on  analyses  and  an  initial 
demonstration  of  the  ATALARS  concept.  he  _asks  and  associated  cost 
to  generate  the  Request  for  Proposal  (RFP)  documentation  (except  for 
the  functional  specification)  for  the  Phase  II  feasibility 
demonstration  are  not  included  in  this  effort. 
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FIGURE  9-1  ATALARS  PROGRAM  PHASE  DEFINITION 
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FIGURE  9-2  ATALARS  -  PROGRAM  SCHEDULE 


One  of  the  most  critical  ATALARS  design  issues  is  the  MMI 
between  the  controller  and  the  ADP  system  and  between  the  pilot  and 
the  aircraft  communications  terminal.  There  are  some  fundamental 
qualitative  requirements  such  as  the  need  for  the  controller  or  the 
pilot  to  "immediately"  grasp  the  importance  of  the  information  being 
presented,  and  the  need  to  present  an  "overview"  to  the  controller 
in  a  manner  which  allows  him  to  focus  on  those  singular  events  that 
require  immediate  attention.  It  is  clearly  feasible  to  meet  the 
data  requirements  delineated  in  Section  6.0.  However,  it  is  not 
immediately  obvious  that  the  above,  and  even  more  subtle, 
qualitative  requirements  can  be  met.  Thus,  a  further  exploration  of 
the  ATALARS  MMI  should  be  accomplished.  This  exploration  should  be 
performed  prior  to  a  more  extensive  effort  to  develop  a  feasibility 
demonstration  model  because  the  data  generated  will  provide  a  more 
definitized  base  for  the  technology  trade-offs  that  are  necessary 
for  the  development  of  a  working  feasibility .demonstration  model. 

9.2.1  Man-Machine  Interface  Requirements  Analysis 

This  task  requires  the  contractor  to  complete  an  analysis  of  the 
ATALARS  MMI  requirements.  this  will  be  an  initial  cut  at  optimizing 
the  controller's  and  pilot's  interaction  with  ATALARS.  The  key 
element  of  this  analysis  is  not  just  to  display  the  data,  but  rather 
how  to  display  the  information  in  easily  usable  form  by  the 
controller  and  pilot.  The  contractor  will  be  required  to  interface 
with  experienced  ATC  personnel  to  acquire  their  operational 
perspective . 

9.2.2  Technology  Review 

This  task  requires  the  contractor  to  review  the  current 
technology  for  evaluating  some  initial  design  considerations 
discussed  in  Section  8.0  (voice  actuated  operator  inputs,  sensors 
for  runway  and  ground  traf Fic  monitoring) .  The  contractor  will  be 
required  to  recommend  the  applicability/f easibility  of  using  this 
technology  in  the  system  design  during  the  follow-on  program  phases. 

9.2.3  Demonstration 


The  principal  contractor  task  for  this  phase  is  to  acquire  and 
assemble  the  hardware  components  and  associated  software  for  the 
man-machine  interface  requirements  demonstration.  Selection  of 
typical  pilot  and  controller  displays  (see  Fable  9-1)  will  be  used 
to  demonstrate  the  ATALARS  capabilities  to  interested  Air  Force 
users.  The  display  demonstration  could  be  accomplished  through  the 
use  of  two  personal  computers  (one  each  for  controller  and  pilot 
displays)  with  a  graphics  software  capability.  (See  Appendix  D  for 
demonstration  hardware/sof tware  considerations.)  The  real  problem 
for  the  contractor  is  to  display  the  aggregated  data  so  that  it 
becomes  information  that  is  readily  understood  by  the  controller/ 
pilot  and  an  immediate  response  (i.e.,  action/no  action)  can  be 
initiated.  One  action  could  be  for  the  controller  to  interact  with 


TABLE  9-1 


ATALARS  SYSTEM  DEMONSTRATION 


ATALARS  VAN 


AIRCRAFT 


DISPLAY  TO  CONTROLLER 


DISPLAY  TO  PILOT 


MLS 

SYSTEM  STATUS  GPS  NONE 

RAPCON 


-  DISPLAY  HANDSHAKE  INFORMATION 
OBTAINED  FROM  THE  AIRCRAFT 

-  CODE 

-  UERIFICATION  -F16 

-FLIGHT 
PLAN  A 
-AIRBASE  X 
-AIRCRAFT  S'  .,TEMS 
STA  rus 


-  DISPLAY  HANDSHAKING 
INFORMATION  TO  THE  PILOT 
(ALERTING  PILOT  THAT  THE  AIR¬ 
CRAFT  HAS  ENTERED  THE  ATALARS 
CONTROL  ZONE.) 


-  DISPLAY  FLIGHT  FOLLOWING  -  NONE 

WITH  NO  ATALARS  ACTION 
(TRACKING  4-  AIRCRAFT 


-  DISPLAY  COLLISION  AUOIDANCE  -  DISPLAY  ATALARS  DIRECTION  TO 

PILOT  (EITHER  CLIMB  TO  5000  FT 
AND  HOLD  OR  DIVE. . . ) 


-  DISPLAY  WEATHER  PROBLEM  - 
WITH  CORRECTIVE  ACTION 
(WIND  SHEAR) 

-  DISPLAY  SEQUENCING  &  SPACING 
PROCESS  (INCL.  TAKEOFF  &■ 
LANDING) 


-  DISPLAY  ATALARS  DIRECTION  TO 
PILOT. . . 


-  DISPLAY  ATALARS  DIRECTION  TO 
PILOT. 


-  DISPLAY  THE  STACKING  PROCESS  -  DISPLAY  ATALARS  DIRECTION  TO 

PILOT. 
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ATALARS  to  obtain  an  additional  level  of  detail  regarding  a  specific 
aircraft.  Several  menu  driven  displays  would  bo  presented  to 
simulate  the  ATALARS  automation  capability  by  providing 
information/ins  true kions  for  use  by  the  controller  and  pilot. 
Additionally,  examples  of  controller/pilot  actions,  as  required,  are 
described  for  each  display.  The  following  displays  provide  some 
critical  conditions  which  may  be  encountered  by  controllerc/pilots 
and  are  recommended  for  use  in  the  demonstration. 

9 . 2 . 3  . 1  Controller  Displays 

9. 2. 3. 1.1  Control  System  Status.  This  display  presents  the 
current  status  of  the  airbase/airfie'ld  control  systems  (e.g.,  MLS, 
ATC  tower,  RSU,  RAPCON)  to  include  date/time  of  latest  update.  The 
display  should  highlight  any  non-operahional  control  systems  and 
trigger  an  appropriate  action  by  a  controller  to  activate  an  ATALARS 
function . 

9.2.3. 1.2  Aircraft  Handshaking.  This  display  identifies 
aircraft  entering  the  ATALARS  control  zone,  provides  aircraft 
status,  correlated  flight  plan  data  to  the  van  subsystem,  and 
requires  an  action  by  the  controller  (i.e.,  aircraft  emergency). 

9.2.3. 1.3  Flight  Following.  This  display  presents  the  tracking 
of  several  aircraft  within  the  control  zone.  The  display  should 
highlight  any  aircraft  deviating  from  its  flight  plan,  and 
therefore,  require  controller  intervention. 

9.2.3. 1.4  Sequencing  &  Spacing.  This  display  presents 
sequencing  and  spacing  of  aircraft  preparing  for  takeoff  and 
landing.  The  displayed  information  would  allow  the  controller  to 
identify  any  improper  sequencing/spacing. 

9. 2. 3. 1.5  Aircraft  Stacking  Process.  This  display  shows  the 
stack  environment  within  the  control  zone  due  to  traffic 
congestion.  Aircraft  are  also  displayed  entering  and  leaving  the 
stack.  The  display  should  alert  the  controller  of  any  aircraft 
requiring  immediate  landing  (e.g.,  emergency  fuel,  aircraft  damage). 

9.2.3. 1.6  Emergency  Condition.  The  displayed  emergency 
condition  would  be  two  ari r craft  on  a  collision  course  and  system 
instructions  to  either/or  both  aircraft.  The  displays  would  alert 
the  controller  of  this  condition  and  the  system  instructions  being 
given.  The  controller  would  monitor  the  condition  and  intervene  if 
appropriate  action  was  not  taken  to  avoid  the  collision. 

9.2.3. 1.7  Severe  Weather  Alert.  This  displays  a  severe  weather 
condition  (e.g.,  wind  shear)  in  the  vicinity  of  an  airfield  and 
corrective  action  instructions  given  to  aircraft  approaching  the 
landing  gates. 
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9.2. 3.2  Pilot  Displays 


5. 2. 3. 2.1  System  Handshaking.  This  display  alerts  the  pilot 
that  the  aircraft  has  entered  an  ATALARS  control  zone  and  confirms 
that  the  on-board  subsystem  has  provided  the  required  data  to  the 
ATALARS  van  subsystem. 

9. 2. 3. 2. 2  Sequencing  &  Spacing.  This  displays  the  instructions 
received  from  the  ATALARS  van  depicting  the  order  of  landing  and 
takeoffs.  It  also  displays  flight  clearance  instructions. 

9. 2. 3. 2. 3  Aircraft  Stacking  Process.  This  displays 
instructions  from  the  ATALARS  van  for  aircraft  entering  a  holding 
pattern  (stack).  The  relative  position  of  other  aircraft  in  the 
stack  will  also  be  displayed. 

9. 2. 3. 2. 4  Collision  Avoidance.  This  displays  instructions  from 
the  ATALARS  van  for  avoiding  a  collision  course.  Highlighting  of 
data  would  be  required  to  alert  the  pilot  to  acknowledge  ATALARS 
direction . 

9. 2. 3. 2. 5  Severe  Weather  Alert.  This  identifies  a  severe 
weather  condition  to  the  pilot  and  including  system  instructions. 
Highlighting  of  data  would  be  required  to  alert  the  pilot. 

9.2.4  Functional  Specification 

The  final  task  is  to  prepare  an  ATALARS  functional  specific¬ 
ation.  The  ATALARS  functions  described  in  Section  6.0  will  form  the 
basis  for  the  specification.  This  continues  the  process  of 
establishing  ATALARS  performance  requirements  for  follow-on  program 
phases.  The  functional  specification  is  a  preliminary  document  that 
will  be  further  refined  during  the  feasibility  demonstration  phase. 

9.3  PHASE  II  CONTRACTOR  TASKING  AND  PRODUCTS 

This  phase  is  intended  to  demonstrate  the  feasibility  of  the 
ATALARS  concept.  In  general,  the  ATALARS  concept  does  not  establish 
requirements  that  are  beyond  the  realm  of  current  or  near-term 
state-of-the-art  hardware  or  software.  In  the  more  specific  sense, 
the  composite  of  the  requirements  needs  an  integration  of  near-term 
technologies;  e.g.,  display  hardware,  expert  system  software, 
information  display  techniques,  data  entry  techniques,  and  others. 
This  combination  of  technologies  must  operate  in  an  environment 
where  failure  to  meet  quantitative  requirements  (e.g.,  response 
time)  and  qualitative  requirements  (e.g.,  situation  recognition)  can 
have  substantial  negative  impacts.  Thus,  it  is  recommended  that  a 
feasibility  demonstration  effort  be  undertaken  prior  to  embarking  on 
full  scale  development  and  risking  the  discovery  that  another  year 
or  two  of  technology  deveiopmer 4  is  necessary.  I  his  demonstration 
would  assure  that  not  only  is  tne  blending  of  the  technologies 
feasible,  but  also  that  the  MMI  can  be  developed  to  meet  the 
requirements  derivable  by  analysis  as  well  as  those  requirements 
which  will  surface  only  during  field  demonstration. 
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It  is  assumed  that  multiple  contracts  will  be  awarded.  Once 
again,  the  task  and  associated  cost  to  generate  RFP  documentation 
for  a  follow-on  phase,  (i.e.,  FSED)  are  not  considered  part  of  the 
contractors'  effort. 


9.3.1  Trade-off  Analyses 

Prior  to  conducting  the  feasibility  demonstration  the 
contractors  will  perform  trade-off  analyses.  These  analyses  should 
address  man-machine  requirement  issues  such  as  the  possibility  of 
employing  artificial  intelligence  to  aid  or  replace  air  traffic 
controller  expertise.  The  results  of  the  technology  review 
conducted  in  Phase  I  would  be  used  to  determine  the  necessity  for 
voice  actuation  in  ATALARS.  The  other  design  considerations 
discussed  in  Section  8.0  should  also  be  included  in  a  trade-off 
analysis  (e.g.,  single  versus  multi-vehicle  design  and 
"leap-frogging"  versus  in-motion  operation) .  The  contractors  should 
also  make  use  of  the  analyses  performed  in  the  Phase  I  effort. 

These  analyses  will  influence  each  contractor's  breadboard 
design  and  should  be  used  in  the  program  office  down  select 
evaluation  process. 

9.3.2  Interoperability  Analyses 

The  criticality  of  ATALARS  interoperability  requires  the  early 
completion  of  these  analyses.  Potential  interfaces  with  airbase 
systems  (e.g.,  ATC  facilities,  weather  monitoring,  weapons  operation 
center),  current  and  future  tactical  systems,  weather  systems,  and 
inter-ATALARS  should  be  considered.  These  analyses  will  provide 
inputs  to  the  ATALARS  family  of  specifications  and  are  precursors  to 
the  interface  control  drawings . 

9.3.3  Class  II  Modification  Package 

All  group  "B  kit"  contractors  and  their  associated  "A  kit" 
contractor  will  be  required  to  prepare  a  Class  II  modification 
package  for  the  selected  aircraft.  The  package  will,  as  a  minimum, 
describe  the  group  "B  kit"  and  group  "A  kit"  requirements ,  and 
include  aircraft  modif ication/dernodification  procedures. 


9.3.4  Conduct  Feasibility  Demonstration 

The  contractors  will  be  required  to  acquire  and  assemble  the 
components  necessary  to  demonstrate  a  breadboard  model  of  ATALARS 
system  through  the  interaction  of  hardware,  software,  displays,  and 
operators.  Both  the  ground  and  aircraft  segments  of  the  system  will 
be  included.  The  automation  concept  of  air  traffic  control  would  be 
demonstrated  through  a  preliminary  design  using  hardware,  higher 
order  language  software,  and  communications  interoperability  of  the 
ATALARS  van  and  aircraft  subsystem.  The  demonstration  would  include 
a  selection  of  critical  system  functions  described  in  Section  6.0 
(airspace  management,  approach  control,  and  airfield  traffic 


-84- 


control) .  As  a  minimum,  those  functions  associated  with  the 
controller  and  pilot  displays  discussed  in  9.2.3. 1  and  9. 2. 3. 2 
should  be  included  in  this  demonstration  plan.  Figure  9-3 
illustrates  a  proposed  pilot  display  depicting  air  traffic  activity 
in  the  vicinity  of  the  aircraft  and  local  airfields. 

9.3.5  System  Specification 

Following  the  down  select  process,  the  contractor  will  prepare  a 
"Type  A"  Specification  for  AFALARS.  This  will  form  the  system 
functional  baseline  for  ATALARS  during  the  FSED  phase. 

9.3.6  Aguisition  Considerations 

The  Phase  I  effort  will  include  the  generation  of  the  system 
specification  that  will  be  the  basis  for  Phase  II.  The  plan  for 
Phase  II  would  be  to  award  three  contracts.  The  effort  would  be  to 
generate  breadboard  hardware  which  will  be  utilized  in  the  field  to 
demonstrate  the  feasibility  of  automating  the  air  traffic  control 
functions  in  the  ATALARS  van  and  the  aircraft  cockpit.  Air  traffic 
controllers  and  pilots  should  be  involved  in  the  early  stages  of  the 
breadboard  design  and  test  effort.  The  breadboard  design  would 
entail  the  development  or  modification  of  two  data  communication 
systems,  one  being  an  airborne  system  and  the  second  being  a  ground 
system.  It  is  envisioned  that  enough  JT1DS  Class  I  and  II  terminals 
(either  prototypes  or  production  assets)  could  be  borrowed  to 
support  the  three  contractors  in  their  design  process. 

To  support  the  field  testing  effort,  1  to  3  aircraft  would  be 
required.  These  aircraft  (either  T-37  or  T-39s)  may  be  available 
from  the  4950th  Test  Wing  located  at  Wright-Patterson  Air  Force 
Base.  The  proposed  schedule.  Figure  9-2,  illustrates  the  worst  case 
of  having  only  one  aircraft  available  for  the  Class  II  modification. 
The  time  frame  illustrated  shows  1  month  for  the  modification,  1 
month  for  the  field  test,  and  1  month  for  the  restoration  of  the 
aircraft.  The  field  demonstration  test  time  could  be  shortened,  if 
more  aircraft  are  available. 


In  order  to  make  the  modifications  to  the  aircraft,  the 
contractors  must  be  teamed  with  an  approved  aircraft  modification 
contractor  or  ESD  must  fund  ASD  to  obtain  the  proper  aircraft 
modification  team.  For  this  effort  it  is  recommended  that  each 
contractor  be  teamed  with  an  "A  kit"  contractor.  This  will  expedite 
the  modification  process. 


Although  not  a  firm  requirement,  use  of  flight  simulators’ prior 
to  field  testing  should  be  investigated.  This  would  give  pilots  an 
opportunity  to  gain  experience  with  ATALARS  before  actual  flight 
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Aircraft  Display 


The  multiple  contractor  approach  should  be  strongly  considered 
Tor  the  feasibility  demonstration  phase.  This  would  provide  a 
variety  of  ATALARS  approaches  io  evaluate,  which  is  highly  desirable 
given  that  ATALARS  repres^::ts  a  new  concept  for  ATC  operations. 

With  the  multiple  contractor  approach,  there  would  be  a  down  select 
decision  after  the  feasibility  demonstration  test.  It  is  important 
to  identify  early  the  ATALARS  ^unctions  to  be  demonstrated  and  the 
criteria  to  be  used  to  select  the  winning  design  approach. 


SECTION  10.0 

CONCLUSIONS  AND  RECOMMENDATIONS 


The  analyses  which  provide  the  basis  for  this  report  suggest 
that  ATALARS  is  technically  feasible  using  current  state-of-the-art 
technology.  1't  is,  however,  also  clear  that  ATALARS  is  on  the 
leading  edge  of  that  technology  and  an  immediate  development  effort 
without  further  analyses  would  present  a  high  risk.  The  critical 
design  and  technology  issues  are  discussed  below. 

The  analyses  did  not  address  operational  viability/feasibility 
or  programmatic  issues  in  detail.  However,  several  were  identified 
and  are  discussed  in  this  section. 

The  recommendations  presented  in  Section  9.0  are  also  summarized 
in  this  section. 

10.1  CRITICAL  DESIGN  AREAS 

The  following  are  considered  critical  ATALARS  design  areas  in 
the  sense  that  they  are  key  to  effective  functioning  of  ATALARS  and 
may  present  difficulties  in  a  development  effort. 

10.1.1  Man-Machine  Interface  -  Controller 

There  are  four  critical  aspects  of  this  interface  between  the 
controller  and  the  ADP  system: 

1.  The  display  of  information  to  the  controller,  not  as  is 
currently  done  in  ATC  systems  on  an  aircraft  by  aircraft 
basis,  but  in  the  aggregate  so  that  the  controller 
understands  the  overall  situation  and  can  identify  situations 
requiring  attention  to  individual  aircraft. 

2.  The  display  of  information  to  the  controller  in  such  a  manner 
that  it  is  immediately  intelligible  in  time  critical 
situations . 

3.  The  rapid  manipulation  of  displays  by  controllers  in  time 
critical  situations. 

4.  Minimization  of  the  time  and  effort  involved  in  data  entry 
into  the  system  when  such  information  is  not  directly  input 
via  data  link . 

10. 1 . 2  Man-Machine  Interface  -  Pilot 

There  are  two  critical  aspects  of  the  interface  between  the 
pilot  and  the  ADP  system: 
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1.  Presentation  of  instructions  and  information  to  the  pilot  in 
a  manner  which  allows  immediate  reaction  in  emergencies  and 
allows  informed  decision  making  on  the  part  of  the  pilot  when 
options  or  limited  guidance  is  provided. 

2.  Minimization  of  time  and  effort  in  providing  the  data  to  the 
ATALARS  system. 

10 . 1.3  Stand-by  Operations 

In  the  highly  volatile  tactical  environment  ATALARS  must  be 
capable  of  assuming  functions  within  minutes  or  seconds  of  the  time 
that  the  need  arises.  This  implies  the  need  for  a  stand-by 
operation  and  a  triggering  mechanism  based  on  monitoring  the 
performance  of  ATC  functions  of  other  facilities. 

10 . 1.4  Remote  Status  Monitoring 

Current  ATC  systems  rely  on  visual  and  other  local  status 
monitoring  systems  (e.g.,  for  runway  monitoring).  ATALARS  must  have 
equally  reliable,  but  remote  and  automated  means  of  status 
monitoring . 

10 . 1.5  Precision  Guidance 

The  criticality  of  ATALARS  being  able  to  provide  comparatively 
precise  guidance  is  clear;  however,  given  a  precise  navigation  such 
as  GPS,  development  of  that  capability  should  be  fairly 
straightforward .  Less  obvious  from  a  design  standpoint  is  the 
development  of  the  mechanisms  and  methodologies  for  compensating  for 
variations  in  navigation  accuracies  and  variations  in  cabilities  of 
systems  (e.g.,  MLS)  with  which  ATALARS  must  interface  or 
interoperate . 

10 . 1.6  Artificial  Intelligence 

ATALARS  is  to  be  designed  as  an  expert  system  which  performs  a 
substantial  portion  of  the  A1C  functions  currently  performed  by  a 
human.  The  determination  of  which  functions  (and  to  what  extent) 
the  expert  system  will  perform  (them)  is  highly  critical  to  the 
effectiveness  of  ATALARS.  The  development  of  an  appropriate 
knowledge  base  is  well  within  the  state-of-the-art;  however,  the 
time  criticality  of  the  environment,  the  necessity  for  the 
man-in-tho-loop  checks  and  balances,  and  the  need  for  establishing 
and  maintaining  "trust"  in  the  expert  system  require  capability 
beyond  that  of  current  expert  systems. 

10.2  TECHNOLOGY  ISSUES 

Technology  issues  associated  with  ATALARS  are  oerivative  of 
critical  design  areas  where  alternative  technologies  are  applicable 
or  the  current  state-of-the-art  is  marginal.  These  include: 
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1.  The  MMI  is  the  area  of  physical  interaction  with  the  system 
for  display  manipulation  md  data  entry  (e.g.,  via  voice) 

2.  The  sensor  portion  of  the  runway  monitoring  subsystem 

3.  The  communications  processing  subsystems  of  the  ATALARS  which 
must  have  the  flexibility  to  maintain  interoperability  with 
evolving  communications  units  of  organizations  with  which 
ATALARS  must  interface. 

10.3  OPERATIONAL  ISSUES 

Two  operational  issues  were  identified  in  the  analysis: 

1.  The  ATALARS  fundamentally  depends  on  appropriately  equipped 
aircraft  to  perform  its  functions.  Provisions  can  be 
incorporated  to  allow  ATALARS  to  p  ovide  ATC  for  aircraft  not 
appropriately  equipped,  but  such  service  may  be  manpower 
intensive  and  involve  degraded  capabilities.  It  is  probable 
that  not  all  U.S.  and  allied  aircraft  operating  in  a  tactical 
environment  will  be  appropriately  and  secularly  equipped. 
Operational  workarounds  may  be  requir  ;-d  t.  avoid  swamping 
ATALARS  controllers  with  servicing  inadequately  or 
inappropriately  equipped  aircraft. 

2.  As  described  in  this  report,  ATALARS  is  fundamentally  for  use 
in  situations  where  "regular"  ATC  services  are  available. 
Thus,  functions  become  operational  as  "regular"  ATC  services 
are  degraded.  ATALARS  would  function  substantially  different 
from  future  ones.  Pilot  (and  controller)  training  must 
address  these  differences  and  accommodate  that  transition  to 
ATALARS  control  will  take  place  in  a  degrading  environment, 
often  in  emergency  situations. 

10.4-  PROGRAMMATIC  ISSUES 


ATALARS  must  interface  or  interoperate  with  other  systems  which 
will  be  developed  or  will  evolve  comparatively  independently  of 
ATALARS  (e.g.,  aircraft  data  link  communications,  aircraft 


navigation  systems,  TAGS  Communications  and  other  ATC  systems).  As 
with  all  systems,  a  degree  of  schedule  and  technical  integration  is 
required  to  assure  operational  capability  when  the  system  is 
fielded.  (If  ATALARS  were  to  be  developed  today  consideration  would 
have  to  be  given  to  the  JTIDS  and  GPS  programs  to  assure  that  these 
systems  were  operational  and  appropriately  interfaced  when  ATALARS 
was  fielded  )  The  nature  of  the  ATALARS  suggests  that  is  will  not 
be  the  driver,  but  rather  that  it  will  be  driven,  with  respect  to 
external  interfaces  and  complementing  systems.  Further,  some  of  the 


design  and 


IVA  vy 


arc  being  addressed  by  other  DOD  and 


FA A  programs,  suggesting  OTS  availability  for  components  of  ATALARS 


in  the  future.  The  specific  issues  identified  are: 
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1.  New  systems  for  exchanging  data  necessary  to  ATALARS  within 
the  TACS  and  external  to  the  TACS  are  being  considered,  but 
not  yet  under  development.  Thus  assuring  ATALARS 
interoperability  with  the  current  TACS  is  inappropriate .  The 
ATALARS  program  must  be  structured  to  accomodate  the 
evolution  of  TACS  communications  as  it  takes  place  to  assure 
interoperability  when  ATALARS  is  fielded  and  when  TACS 
communications  are  upgraded  thereafter. 

2.  Similarly,  aircraft  communications  are  evolving.  To  avoid  a 
requirement  for  an  ATALARS  terminal  to  be  installed 
(retro-fitted)  into  aircraft,  the  same  approach  must  be  taken 
to  this  interface  as  to  the  TACS  interface. 

3.  There  are  current  EAA  programs  to  automate  ATC  functions  and 
to  provide  runway  data.  If  these  are  nearing  fruition  as 
ATALARS  reaches  the  development  stage,  consideration  should 
be  given  to  integrating  aspects  of  these  programs  with  the 
ATALARS  development. 

10.5  RECOMMENDATIONS 

Prior  to  proceeding  with  the  development  of  ATALARS  we  feel  that 
additional  analysis  of  technical  capabilities  are  required  which 
would  proceed  a  demonstration  of  the  ATALARS  concept.  This  effort 
includes : 

1.  The  necessity  to  verify  that  the  system  is  feasible  from  a 
human  factors  standpoint,  i.e.,  that  state-of-the-art  MMI 
technology  can  be  applied  to  develop  an  ATALARS. 

2.  The  review  of  current  technology  for  critical  design  areas; 
i.e.,  display  manipulation,  data  entry,  and  sensor  use  for 
runway  monitoring. 

3.  Trade-off  analyses  for  use  of  artificial  intelligence  to  aid 
or  replace  controller  expertise,  van  subsystem  design,  and 
interoperability  with  interfacing  systems. 

4.  Verification  that  the  system  is  operationally  acceptable  to 
controllers  and  pilots  and  can  indeed  provide  a  safe, 
efficient  and  effective  ATC  environment. 

To  address  the  first  two  items,  we  recommend  a  short  study  contract 
to  address  the  MMI  problem  and  investigate  technology  issues.  To 
address  the  last  two  items,  we  recommend  a  contract  to  conduct 
trade-off  analyses  and  develop  a  minimally  capable  breadboard  system 
which  is  integradable  with  current  ATC  simulators  and  demonstrable 
on  flight  test  ranges. 
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APPENDIX  A 

FUNCTIONAL  ANALYSIS  METHODOLOGY 


This  appendix  describes  the  methodology  used  in  the  ATALARS 
functional  analysis.  A  top-down  structured  approach  was  used  to 
identify  and  define  the  required  A'lALARS  operational  functions. 

This  technique  treated  ATALARS  as  a  black  box  of  unspecified  design 
which  performs  certain  operational  functions  (e.g.,  flight 
following).  These  functions  were  further  decomposed  into 
subfunctions,  activities,  subactivities,  tasks,  subcasks,  etc.,  to  a 
level  of  detail  consistent  with  maintaining  independence  of  design. 
More  specifically,  if  further  decomposition  required  a  design 
decision  such  as  allocation  between  man  and  machine,  the 
decomposition  process  was  complete. 

The  output  of  the  decomposition  process  is  a  functional 
hierarchy  such  as  depicted  in  Figure  A-l.  Section  6.0  presents  and 
discusses  the  functional  hierarchy  developed  for  ATALARS.  In  this 
report,  the  term  "function"  was  used  genencally  and  applied  to  all 
levels  of  the  functional  hierarchy. 

The  results  of  this  functional  decomposition  were  merged  with  a 
subsequent  decomposition  of  ATALARS  into  functional  subsystems 
(e.g.,  database  management,  display)  as  depicted  in  Figure  A-2 .  The 
merging  took  the  form  of  allocating  the  lowest  level  of  operational 
functional  elements  to  the  appropriate  functional  subsystem.  This 
then  provides  a  system  functional  baseline  for  further  design 
efforts . 

The  decomposition  process  is  applicable  not  only  to  the 
development  of  a  functional  hierarchy,  but  also  to  functional  flow 
diagrams,  N2  diagrams,  and  input/output  (interface)  requirements 
as  depicted  in  Figure  A-3 .  These  aspects  of  the  decomposition 
combined  with  allocation  of  numerical  requirements  provide  the  basis 
for  the  eventual  functional  specification  for  the  system.  These 
alternative  depictions  also  provide  checks  on  consistency  and 
completeness  of  the  functional  hierarchy  and  associated  data.  The 
N2  diagrams  assure  that  each  input  for  a  functional  element  has  a 
source.  The  functional  flow  assured  that  each  functional  element 
belonged  in  a  sequence  and  that  all  elements  needed  for  a  sequence 
are  defined. 

The  body  of  data  developed  for  each  functional  element  is 
pictorially  shown  in  Figure  A-4.  Figure  A-5  presents  a  sample  of 
the  data  sheets  used  to  maintain  the  information  on  each  functional 
element.  These  data  sheets  have  been  developed  for  each  functional 
element  described  in  Section  6.0  and  were  completed  as  necessary 
during  the  aggregation/allocation  process. 
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FUNCTIONAL  HIERARCHY 


FIGURE  A -2 

AGGREGATION  AND  ALLOCATION 


FUNCTIONAL  FLOW  N  DIAGRAM 


FIGURE  A -3 

OTHER  APPLICATION  OF  DECOMPOSITION 


FIGURE  A -4 

FUNCTION  DESCRIPTION 


FUNCTIONAL  AREA:  Airspace  Management 

FUNCT IONAL  PROCESS  NO.  6.1.1  P 1 ann i ng/Coord i nat i on 

TITLE:  Airspace  Acquisition 

DESCRIPTION:  Define  airspace  for  which  ATALARS  has  control 
responsibility 


SOURCE 

CONTENT 

FORMAT 

TRIGGERS 

Establishment  of  need 
(inc.  new  operations  cycle) 

HQTAF,  Clock 

Requirements  (mission) 
boundary  locations 
(latitude,  longitude) 
Bases/airfields  being 
supported 

INPUTS 

External  Interfaces 
(inc.  Control  Authority(s)) 

TACC  etc. 

Interface  10  (name, 
method  of  control: 

IFR,  VFR) 

Boundary  Locations 

TACC  etc. 

length,  width,  height 
(sections) 

Special  Instructions 

HQTAF,  TACC 

limitations  or  extended 
functions 

PROCESS 

Initialize  system, 

Initialize  databases 

DATABASE: 

Airspace  Boundary  Definition 
Interface  Definition 

OUTPUTS 

Coordination  with  all 
external  interfaces 

CRC,  AWACS  etc. 
also  Army/ 

Airbase  Air  Defense 
and  Base/Airfield 

ATC  tower 

ATALARS  ID  hand-shake 
(scope  of  control: 
boundary,  priority, 
limitations) 

PASS  PROCESS  TO 

Control  Coordination 

internal  link 

FIGURE  A-5 
DATA  SHEET 
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APPENDIX  B 

ATALARS  FUNCTIONAL  HIERARCHY 


Tables  B-l  through  B-4  present  the  ATALARS  functional  hierarchy 
using  a  numbering  scheme  which  corresponds  to  that  used  in  Section 
6.0  of  this  report. 


Table  B-l 

6.1  AIRSPACE  MANAGEMENT 


1.1.2 
6 . 1 . 1 .2  .  1 


6.1.1  Planning/Coordination  (Next  Ops  Period) 

<5 . 1 . 1 .  1  Airspace  Acquisition 

6.1. 1.1.1  Airspace  Boundary  Definition 

6.  1.1. 1.2  Airspace  Interface  Coordination 

6.1. 1.1.3  Airspace  Acquisition 

6. 1.1.2  Control  Function  Coordination 

6.1. 1.2.1  Control  Function  Allocation 

6.1.  1.2.2  Control  Interface  Definition 

6.  1.1.2. 3  Control  Establishment 

6 . 1 . 1 . 2 . 4  Adjustments 

6.1.2  Environment  Monitoring 

6 . 1 . 2  .  1  Weather 

6. 1.2.2  Enemy  Activity 

6.  1.2.3  Airspace  Utilization 

6. 1.2.4  Friendly  Air  Defense 

6.1.3  Air  Traffic  Monitoring 

6. 1.3.1  Aircraft  Tracking 

6.  1.3.2  Aircraft  Identification 

6. 1.3.3  Emergency  Detection/Assessment 

6.1.4  Air  Traffic  Control 

6. 1.4.1  Aircraft  Handoff 


Enemy  Activity 
Airspace  Utilization 
Friendly  Air  Defense 
3 

Aircraft  Tracking 
Aircraft  Identification 
Emergency  Detection/Assessment 

Aircraft  Handoff 


1.4.2 


Aircraft  Routing 


6. 1.4.3  Aircraft  Sequencing  and  Spacing 

6. 1.4.4  Emergency  Response 


Table  B-2 

6.2  APPROACH  CONTROL 


6.2.1  Aircraft  Route  Selection 


6.2.  1.  1 

Airbase  Selection 

6.2. 1.1.1 

Aircraft  Requirements  Assessment 

6.2.  1.  1.2 

Airbase  Status  Review 

6.2. 1.  1.3 

Airbase  Selection 

6.2.  1.2 

Situation  Analysis 

6.2. 1 .2. 1 

Airspace  Environment  Analysis 

6.2. 1.2.2 

Air  Traffic  Situation  Analysis 

6.2. 1.3 

Route  Selection 

2  Approach  Environment 

Monitoring 

6.2.2. 1 

Weather 

6. 2. 2. 2 

Enemy  Activity 

6. 2. 2. 3 

Friendly  Air  Defenses 

6. 2. 2. 4 

Interfacing  Control  Systems 

6. 2. 2. 5 

Emergency  Identification /Notification 

6. 2. 2. 6 

Issue  Advisories 

6.2.3  Stack  Operations  Monitoring 

6.2.3. 1  Aircraft  Tracking 

6. 2. 3. 2  Emergency  Detection/Assessment 

6.2.4  Stack  Operations  Control 


6.2.4. 1 

Aircraft  Handoff 

6. 2. 4. 2 

Stack  Insertion 

6. 2. 4. 3 

Stack  Traffic  Control 

6. 2. 4. 4 

Stack  Extraction 

6. 2. 4. 5 

Runway  Monitoring 

6. 2. 4. 6 

Emergency  Response 

6.2. 5  Information  Dissemination 

6.2.5. 1  Aircraft  Notification 

6. 2. 5. 2  Controller  Notification 

6. 2. 5. 3  Air  Defense  Notification 
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I  6.3 

Table  B-3 

AIRFIELD  TRAFFIC  CONTROL 

j§j  6.3.1  Traffic  Scheduling 

6 . 3  . 1 .  l 

Assessment  Landing  Requirements 

I  6.3. 1.1.1 

Scheduled  Planning 

6.3. 1. 1.2 

Current  Scheduling 

■  6.3.  1.2 

Assessment  Takeoff  Requirements 

"  6.3.  1.2. 1 

Schedule  Planning 

■  6.3. 1.2.2 

Current  Scheduling 

•  ■  6 . 3  .  1 .  3 

Current  Airbase  Capabilities/Status 

Assessment 

!  |  6.3. 1.4 

Time  Slots  Establishment 

6.3.2  Airfield  Status  Monitoring 

1  6.3.2. 1 

Control  Systems 

6. 3. 2. 2 

Runways 

■  6. 3.2.3 

Taxiways 

*  6. 3. 2. 4 

Support  Facilities 

|  6. 3. 2. 5 

Issue  Advisories 

■  6.3.3  Monitor  Patterns 

|  6 . 3  .  3  .  1 

Aircraft  Tracking 

1  6 . 3  .  3 . 2 

Emergency  Detection/Assessment 

r  6.3.4  Monitor  Ground  Traffic 

1  mi 

|  6. 3. 4.1 

Runways 

6. 3. 4. 2 

Taxiways 

jl  6.3.B  Landing  Control 

6 . 3 . 5 . 1 

Aircraft  Handoff 

|  6 . 3 . 5 . 2 

Landing  Sequencing  and  Spacing 

■  6 . 3 . 5 . 3 

Aircraft  Guidance 

5  |  6-3-5-4 

Emergency  Response  (inc.  missed 
approach) 

6.3.6  Departure  Control 

|j  ■  6.3,7  Ground  Traffic  Control 

f  6 . 3 . 7  .  1 

Runway  Control 

:  |  6. 3. 7. 2 

Taxi  Control 

1  6. 3. 7. 3 

!  | 

Emergency  Response 

}  1 

ii 
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Table  B-4 

6.4  EXERCISE/TRAINING 


6.4.1  Planning 

(Same  as  6.1.1,  but  inputs  different) 


6.4.2  Range  Control  Interfa 

6.4.2.  1 

6. 4. 2.  -2 

6. 4. 2. 3 

6.4.3  Civilian  ATC  Interfac 

6 . 4 . 3  .  1 

6. 4. 3. 2 

6. 4. 3. 3 

6.4.4  Data  Collection 
6 . 4 . 4 .  1 

6. 4. 4. 2 

6.4.5  Simulation 
6 . 4 . 5  .  1 

6. 4. 5. 2 


e 

Flight  Safety  Coordination 
Track  Data  Exhange 
Handoff 

Near  Term  Planning  Data  Exhange 
Track  Data  Exchange 
Military  Aircraft  Handoff 

Post  Exercise  Evaluation 
Situation  Reconstruction 

Exercise  Support 
Training 
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APPENDIX  C 

PHASE  I  &  II  COST  ESTIMATES 


1.0  INTRODUCTION 

This  Appenidx  contains  the  initial  cost  estimates  to  accomplish 
the  ATALARS  program  and  demonstration  planning  efforts  described  in 
Section  9.0  of  this  report.  Included  are  all  tasks  associated  with 
the  Phase  I  Initial  Demonstration  and  the  Phase  II  feasibility 
Demonstration.  Phase  I  consists  of  the  four  tasks  as  described  in 
Sections  9.2.1  through  9.2.4,  respectively .  Phase  II  consists  of 
three  tasks:  (1)  Analyses  as  described  by  Sections  9.3.1  &  9.3.2; 

(2)  Feasibility  Demonstration  as  described  in  Sections  9.3.3  & 

9.3.4;  and,  (3)  System  Specification  as  described  by  Section  9.3.S. 
Each  phase  also  includes  considerations  for  Other  Government  Costs 
such  as  Government  Furnished  Equipment  (GFE),  and  Engineering  & 
Management  support. 

The  estimating  approach  relied  upon  the  technical  description 
and  program  schedule  contained  in  Section  9.0,  as  well  as  expanded 
information  obtained  through  direct  conversation  with  authors  of  the 
report.  The  primary  estimating  methodology  is  manloading  based  upon 
engineering  assessments  with  all  man  months  costed  at  $10K  in  FY87 
dollars.  Major  exceptions  to  this  are  the  Phase  II  software,  GFE, 
and  material  estimates.  Relevant  groundrules,  assumptions,  and 
details  will  be  introduced  within  the  respective  sections  to  which 
they  apply. 

The  estimates  were  performed  in  BY87  dollars.  All  escalation 
used  the  Revised  OSD(C)  Inflation  Factors  dated  11  December  86.  The 
entire  effort  has  been  assumed  to  fall  within  the  Research  & 
Development  (3600)  Appropriation .  A  summary  of  the  estimates  phased 
in  constant  BY87$  and  TY$  is  shown  below.  Note:  A  key  assumption 
that  Phase  II  has  three  additive  estimates,  each  representing  one  of 
three  assumed  contractors. 


Phase  I  &  11  Summary  Estimates 
F Y 8 7 $  in  Millions  (3600) 


FY87 

FY88 

FY89 

FY90 

TOTAL 

Phase  I 

.08 

.91 

,05 

1.04 

Phase  II 

(1) 

- 

- 

8.45 

3.02 

1 1 . 47 

Phase  II 

(2) 

... 

- 

8 .35 

2  .  37 

10.72 

Phase  II 

(3) 

- 

— 

8.35 

2.37 

10.72 

TOTAL 

.08 

.91 

25.20 

7 . 76 

33.95 

Inflation 

Indices  ( BY87/3600/1 1DEC86) 

1.024 

1.060 

1.095 

1 .  128 

TY$  in  Millions 

FY87 

FY88 

FY89 

FY90 

TOTAL 

Phase  I 

0. 1 

1.0 

0. 1 

— 

1.2 

Phase  II 

(1) 

- 

- 

9.3 

3.4 

12.7 

Phase  II 

(2) 

- 

- 

9. 1 

2.7 

11.8 

Phase  II 

(3) 

— 

— 

9.1 

2.7 

11.8 

TOTAL 

0.1 

T.o 

27.6 

O' 

37 . 5 
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2.0  PHASE  I 

Described  are  the  Labor  &  Material  costs  of  four  tasks 
associated  with  the  contractual  effort,  as  well  as  other  government 
costs  for  Engineering  &  Management  support.  A  summary  by  task  is 
shown  below.  Costing  details  are  included  in  the  Following 
paragraphs;  technical  descriptions  of  each  task  are  in  Sections 

9.2.1  through  9.2.4. 


Phase  I 

FY8V$  in  Thousands 


Task  1  180 
Task  2  90 
Task  3  490 

Task  4  _ 180 

Contract  940 
Eng.  Spt.  45 
Mgt .  Spt.  _ 55 
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2.1  TASK  1:  MAN-MACHINE  REQUIREMENTS  ANALYSIS 

The  effort  is  entirely  labor,  estimated  by  manloading  and  based 
upon  an  engineering  assessment.  The  task  will  be  an  initial  cut  at 
optimizing  the  controller's  and  pilot's  interaction  with  ATALARS. 

2.2  TASK  2:  TECHNOLOGY  REUIEW 

The  effort  is  entirely  labor,  estimated  by  manloading  and  based 
upon  an  engineering  assessment.  The  task  will  include  a  review  of 
current  technology  to  evaluate  initial  design  considerations,  i.e., 
voice  actuated  operator  inputs,  sensors  for  runway  and  ground 
traffic  monitoring. 

2.3  TASK  3;  DEMONSTRA TION 

Labor  costs  account  for  $480K  with  the  remaining  $10K  required 
for  hardware.  The  three  categories  of  labor  are  Systems  Engineering/ 
Program  Management  (SE/PM)  ($180K),  ATC/Pilot  Expertise  ($60K),  and 
Software  Development  ($240K).  The  SE/PM  effort  requires  a  lead 
Engineer/Manager  to  coordinate  system  level  design  and  provide 
ongoing  analysis  of  the  detailed  design.  An  additional  individual 
will  be  required  during  the  last  six  months  to  assist  with 
analysis.  Expertise  of  operational  specialists  is  required  to 
insure  a  satisfactory  requirements  analysis  and  preliminary  design. 
Software  Development  will  be  accomplished  by  a  small  team  consisting 
primarily  of  analysts.  Their  product  will  be  software  to  generate 
graphics  displays.  All  the  above  manloadings  are  based  on 
engineering  assessments.'  The  software  assessment  is  based  on  an 
analogy  to  a  similar  development  of  a  graphics  display  designed  to 
simulate  the  tracking  function. 

The  hardware  consists  of  two  desktop  computers,  two  small 
displays,  and  minor  peripherals .  The  IBM  AT  and  Kodak  Data  Show 
(See  Appendix  D)  are  used  as  points  of  comparison  for  cost. 


2.4  TASK  4:  FUNCTIONAL  SPECIFICATION 

The  effort  is  entirely  labor,  estimated  by  manloading  and  based 
upon  an  engineering  assessment.  The  task  will  prouidc  a 
preliminary  functional  specification  for  ATALARS. 

2.5  ENGINEERING  SUPPORT 

Assumes  a  manmonth  prior  to  contract  award  to  prepare  Request 
for  Proposal  (RFP)  documentation  and  3.5  manrnonths  after  completion 
for  follow-on  Government  analysis. 

2.6  MANAGEMENT  SUPPORT 

Assumes  a  manmonth  prior  to  contract  award  and  4.5  manrnonths 
after  completion.  Each  effort  is  associated  with  preparation  of  RFP 
documentation . 

3.0  PHASE  II 

Described  are  the  Labor  &  Material  costs  of  the  three  tasks 
associated  with  the  contractual  effort,  as  well  as  Other  Government 
Costs  such  as  GTE  and  Engineering  &  Management  support.  A  summary 
by  task  for  each  of  three  contractors  is  shown  below.  Costing 
details  are  included  in  the  following  paragraphs;  technical 
descriptions  of  each  task  is  contained  in  Section  9.3  as  specified 
in  paragraph  1.0  of  this  Appendix. 


Phase  II 

FY87$  in  Thousands 


(1) 

(2) 

(3) 

TOTAL 

Task  1 

900 

900 

900 

2700 

Task  2 

7480 

7210 

7210 

21900 

Task  3 

240 

— 

— 

240 

Contract 

8620 

8110 

8110 

24840 

GFE 

2500 

2500 

2500 

7  500 

Enq.  Spt. 

110 

110 

110 

330 

Kgt.  Spt. 

240 

— 

— 

240 

11470 

10720 

10720 

32910 

3 . 1  TASK  1 :  ANALYSES 

Approximately  ton  trade- off  and  five  interoperability  studies 
are  anticipated.  An  engineering  assessment  of  6  manrnonths  per  study 
was  used  to  manload  this  requirement. 

3.2  TASK  2:  FEASIBILITY  DEMONSTRATION 

Included  are  all  contractor  efforts  necessary  to  design, 
manufacture,  test  and  demonstrate  the  breadboard  system.  Major  cost 
elements  include  Group  B,  Group  A/Install,  Flight  Test,  SE/PM,  Data, 
and  Engineering  Change  Order  (ECO). 

3.2.1  Group  B 

Components  include  hardware,  software  and  integration.  Hardware 
and  labor  estimates  consider  design  &  manufacture  of  unique  items  as 
well  as  modifications  to  GFE  items.  Unique  items  include  an  air 
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conditioned,  fully  powered  van  and  the  necessary  processing  & 
display  equipment.  Modifications  to  the  data  terminals  and  ATC 
emulator/simulator  will  be  required.  Estimates  of  $350l<  for  design, 
$300K  for  manufacture,  and  $300K  for  material  are  engineering 
assessments . 

Software  estimates  consider  the  requirerrir  s  analysis,  design, 
code/unit  test,  integration  and  hardware/sof tware  integration.  The 
effort  results  in  software  which  permits  demonstration  of  the 
functions  associated  with  controller  &  pilot  displays  as  described 
in  Sections  9.2.3. 1  &  9. 2. 3. 2.  Being  prototype  by  nature  and 
targeted  for  a  breadboard  system,  it  is  assumed  that  strict 
compliance  with  military  standards  for  testing,  reliability, 
documentation,  etc.,  will  not  be  required.  Also,  while  demanding  a 
certain  amount  of  real-time,  interactive  capability,  it  is  assumed 
that  the  specification  will  be  somewhat  flexible,  allowing 
work-arounds  and/or  simulations.  As  such,  the  COCOMO  definition  of 
the  semidetached  mode  of  development  is  considered  appropriate. 

Each  of  the  12  displays  is  sized  at  an  average  of  5000  Lines  of  Code 
(LOG)  of  nominal  complexity.  Multiplied  by  12  for  total 
development,  the  effort  rounds  to  200  manrnonths .  Requirements 
analysis  &  hardware/sof tware  integration  are  estimated  as  10%  &  30%, 
respectively.  This  equates  to  10  LOC/day  (60KL.0C/280  MMTH)  for  the 
fully  integrated  software. 

3 . 2 . 2  Group  A/Install 

Contained  is  a  nominal  6  rnanmonth  effort  by  the  prime  contractor 
to  genera4  <5  an  interface  package  and  a  subcontract  to  an  integration 
contractor  amounting  to  $1.0M  to  accomplish  the  Class  II 
modification.  The  subcontract  amount  is  based  on  an  analogy  to  a 
$9M  Class  U  modification  program  with  five  Line  Replaceable  Units 
(LRUs).  The  $1.0M  is  considered  appropriate  given  a  breadboard 
model  of  a  single  LRU. 

3.2.3  Flight  Test 

Contained  is  a  nominal  6  rnanmonth  effort  by  the  prime  contractor 
at  the  test  facility. 

3.2.4  Systems  Engineering/ Program  Management 

Maoloaded  estimates  of  83  &  55  manrnonths  are  based  upon 
engineering  assessments  of  the  requirement .  This  equates  to  19%  of 
Prime  Mission  Equipment  (PME)  (Group  B,  Group  A/Install,  GFE) . 

3.2.5  Data 

A  manloaded  estimate  of  58  manrnonths  equating  to  8%  of  PME  is 
assessed , 


3.2.6  ECO 

Estimated  as  approximately  10% 

3.3  TASK  3:  SYSTEM  SPECIFICATION 
This  task  will  be  performed  by 
III.  A  manloading  of  24  manrnonths 
not  directly  attributable  to  the  A 


of  PME. 


the  contractor  selected  for  Phase 
is  assessed  as  reasonable.  While 
Specification  preparation,  this 
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task  will  require  a  low  level  presence  within  SE/PM  &  Data  Cost 
Elements.  This  amounts  to  $270K  during  the  final  6  months  of 
performance . 

3.4  GOVERNMENT  FURNISHED  EQUIPMENT  (GFE) 

Required  are  two  data  terminals  and  an  ATC  Emulat lon/Simulation 
capability.  It  is  assumed  that  two  JTIDS  Class  2  terminals  priced 
at  $1.2M  each  and  requiring  minimal  modification,  as  well  as  an 
AN/GPN-T4  priced  at  $0.1M  will  be  available  for  each  contractor  in 
FY89 . 

3.5  ENGINEERING  SUPPORT 

Included  is  a  $75K  requirement  for  the  test  facility  and  3.5 
manmonths  for  a  foilow-on  analysis. 

3.6  MANAGEMENT  SUPPORT 

Included  is  a  manmonth  for  contract  monitoring  during  each  of 
the  14  months  of  the  contract.  Month  30  includes  ten  manmonths  for 
the  downselect  process.  This  effort  is  not  impacted  by  multiple 
contracts . 

4.0  CONFIDENCE  LEVEL  ASSESSMENT 

The  overall  confidence  level  of  these  estimates  is  very  much 
dependent  upon  the  technical  descriptions  available.  Since  it  is  a 
conceptual  phase,  Phase  I  is  primarily  a  Level  of  Effort  (LOE)  study 
intended  to  refine  the  definition  of  Phase  II.  As  such,  cost  & 
schedule  uncertainty  of  Phase  I  is  relatively  low.  The  cost  & 
schedule  estimates  of  Phase  II,  however,  being  very  much  dependent 
upon  the  results  of  Phase  I  requirements  analysis,  technology  review 
and  functional  specification,  have  more  inherent  uncertainty. 
Subsequent  estimates  with  these  jsults  should  be  performed. 

The  general  estimating  methodologies  present  another  factor 
which  impacts  the  overall  confidence  level.  Two-thirds  of  the 
estimate  is  labor.  Manloadings  based  upon  engineering  assessments 
are  responsible  for  42%  of  the  $11.47M  for  the  first  Phase  II 
contractor.  Another  25%  is  derived  by  COCOMO  for  the  software 
effort.  Finally,  33%  is  derived  by  engineering  assessments  of 
material  requirements . 
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APPENDIX  D 

PHASE  I  DEMONSTRATION  HARDWARE/SOFTWARE  CONSIDERATIONS 


This  appendix  contains  a  review  of  current  state-of-the-art 
hardware  and  software  capabilities  for  consideration  in  the  Phase  I 
demonstration . 

1.0  INTRODUCTION 

The  man-machine  interface  may  require  highly  specialized 
capabilities  for  demonstrating  the  automation  of  the  system.  For 
example,  enhanced  graphics  and  color  are  basic  necessities  in  a 
pilot's  heads-up  display  or  a  controller's  display.  The  processing 
speed  is  also  a  critical  requirement  to  simulate  real-time  system 
Functionality.  As  each  requirement  becomes  an  option  in  the 
demonstration,  cost  and  complexity  become  the  key  to  determining  the 
system's  quality  and  accuracy  in  simulating  an  ATALARS  environment. 
This  results  in  a  series  of  trade-offs  which  identify  limitations 
using  various  off-the-shelf  systems.  The  following  paragraphs 
present  the  capabilities  of  various  hardware/sof tware  which  can  be 
the  basis  for  these  trade-offs. 

1.1  HARDWARE 

An  IBM  PC/XT/AT  or  compatible  system  has  the  most  flexibility 
and  is  generally  the  most  expensive.  It  is  less  portable  than  other 
systems  available  (a  laptop  system) .  Color  and  enhanced  graphics 
are  available  on  most  models  (again  except  for  the  laptop)  but  both 
high  resolution  color  monitors  and  enhanced  graphics  adapter  cards 
are  specialized  options.  Due  to  the  processing  speed  needed  (8  MHz 
will  probably  be  the  minimum  required),  the  higher  priced,  more 
elaborate  XT  or  AT  models  are  more  appropriate. 

For  enhanced  graphics,  the  industry  continues  to  emulate  the 
Apple  Macintosh.  The  major  drawback  is  its  lack  of  color  (all 
shading  is  done  in  grey  scale).  However,  the  system  comes  complete 
allowing  full  use  of  its  graphics  capabilities.  The  system  is  also 
portable,  since  the  monitor  is  built  in. 

Display  technology  is  one  aspect  of  an  ATALARS  implementation 
that  could  be  demonstrated.  The  high  resolution  and  color  that  is 
currently  available  using  CRTs  will  enhance  the  man-machine 
interface;  however,  LCD  or  plasma  technology  may  be  more  appropriate 
in  a  mobile/tactical  ATALARS  environment.  On  a  more  practical 
level,  LCD  or  plasma  displays  are  more  portable,  as  evidenced  by 
their  use  in  laptop  personal  computers.  This  portability  could  be 
very  desirable  when  taking  the  demonstration  to  Air  Force  users. 

The  obvious  drawbacks  of  LCD  and  plasma  technology,  including  lack 
of  color  and  limited  graphics,  would  be  expected  to  decrease  as 
these  technologies  evolve. 

A  PC-based  graphics  system  should  provide  the  most  complete, 
user-friendly  environment  to  support  the  ATALARS  rnan-rnachnie 
demonstration.  A  dedicated  graphics  workstation  would  be  roughly 
four  times  as  expensive,  less  user-f riendly ,  and  would  probably  not 
provide  as  many  options.  The  graphics  capabilities  gained  from  a 
dedicated  workstation  would  also  far  exceed  any  design  requirements 
generated  for  ATALARS  at  this  point  of  development. 


1.2  SOFTWARE 

There  are  many  software  graphics  packages  available  in  the 
micro-computer  industry.  Packages  such  a  Lotus'  Freelance  and 
Microsoft's  Micrographics  Windows  Draw  provide  very  extensive 
graphics  capabilities;  however,  features  such  as  animation  may  still 
be  difficult  to  duplicate.  These  graphics  packages,  having  been 
designed  for  freehand  static  presentations,  may  actually  make 
displaying  objects  in  an  ATALARS  Format  more  difficult.  The 
majority  of  graphics  packages  will  make  the  most  of  a  system's 
capabilities  and  provide  elaborate  graphics;  however,  they  may  also 
require  specific  system  enhancements. 

Languages  such  as  Microsoft's  BASIC  Version  2.0  do  allow  for 
graphics  The  strength  of  a  general  purpose  language  is  that  the 
graphic  symbol  library  consists  of  essential  primitives  such  as 
lines  and  arcs.  In  simulating  an  ATALARS  environment,  these 
primitives  allow  the  programmer  to  design  the  display  formats 
without  being  constrained  to  the  formats  available  in  the  graphics 
package.  This  method,  while  only  providing  simple  representations , 
allows  more  flexibility  when  attempting  to  animate  the  various 
scenarios.  To  allow  a  language  such  as  BASIC  to  provide  quality 
graphics  and  animation  will  require  very  high  processing  speeds 
(8-16  MHz)  such  as  those  found  in  the  80286-based  IBM  PC/ATs  or  the 
80386-based  Compaq  Deskpros. 

1.3  VISUAL  ENHANCEMENTS 

Because  of  the  need  to  demonstrate  this  system  to  a  sizeable 
audience  at  many  locations,  visual  enhancement  systems  need  to  be 
addressed.  These  systems  may  also  serve  to  enhance  the  man-machine 
interface  by  simulating  some  ATALARS  characteristics .  The  most 
promising  of  these  systems  is  the  Kodak  Data  Show.  The  Data  Show 
employs  LCD  technology  by  taking  the  RGB  output  from  the  PC  and 
displaying  the  information  on  a  liquid  crystal  screen  overlayed  on 
an  overhead  projector.  The  drawbacks  would  be  the  limitation  of  the 
LCD  technology  and  compatibility  requirements  with  systems  other 
than  an  IBM  PC, 

Slide  systems  such  as  the  Polaroid  Pallette  or  Celtic 
Technologies  VFR-2000  Screen  Camera  provide  strong  graphics  and 
color  enhancements  even  making  color  slides  from  monochrome 
displays.  In  addition  to  systems  providing  in-house  capabilities, 
there  are  also  graphics  services  available  from  outside  vendors. 
However,  since  slides  are  obviously  a  static  medium,  their  use  would 
not  support  animation  or  an  on-line  demonstration.  To  make  slides 
work  in  an  automated  environment,  a  system  called  Video  Show  can  be 
used.  This  system  provides  the  ability  to  save  graphic  images 
generated  on  a  PC  and  present  them  with  various  transitional 
sequences  to  allow  a  graphic  flow  from  image  to  image.  Again,  the 
transitions  are  not  conducive  to  animation.  The  Video  Show  does 
provide  extended  graphics  and  color  capabilities  and  is  highly 
portable.  All  of  these  visual  support  systems  are  based  on  the  use 
of  static  graphics  and  text,  so  their  use  in  an  animated 
demonstration  would  be  considered  non-standard  at  best. 
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GLOSSARY 


AADCP 

AAFCE 

ADP 

AJ 

ATAF 

ATALARS 

ATC 

ATDL 

AIDS 

A  TO 

AWACS 

AWS 

C2 

CAFMS 

CBR 

COTS 

CRC 

CRP 

CRT 

DBMS 

DDP 

DOD 

DRAM 

ECO 

EMP 


ESD 

ETA 

FAA 

FACP 

FEBA 

FLOT 

FSP 


FSED 

GFE 

GPS 

HQ  TAF 

ICAO 

ID 

IFF 

INS 

JTIDS 

LCD 

LOC 

LPI 

LRU 

MCE 

MLS 

MM  I 

MMLS 

MPC 


Army  Air  Defense  Command  Posts 
Allied  Air  Forces  Central  Europe 
Automated  Data  Processing 
Anti- Jam 

Allied  Tactical  Air  Force 

Automated  Tactical  Aircraft  Launch  and  Recovery  System 

Air  Traffic  Control 

Army  Tactical  Data  Link 

Air  Tactical  Data  System 

Air  Task  Order 

Airborne  Warning  and  Control  System 
Air  Weather  Service 
Command  and  Control 

Computer  Automated  Force  Management  System 

Chemical  Biological  Radiological 

Commercial  Of f-the-Shelf 

Control  and  Reporting  Center 

Control  and  Reporting  Post 

Cathode  Ray  Tube 

Data  Base  Management  System 

Digital  Data  Processor 

Department  of  Defense 

Dynamic  Radorn  Access  Memory 

Engineering  Change  Order 

Electromagnetic  Pulse 

Electronic  Systems  Division 

Estimated  Time  of  Arrival 

Federal  Aviation  Administration 

Forward  Air  Control  Post 

Forward  Edge  of  Battle  Area 

Forward  Location  of  Troops 

Full  Scale  Production 

Full  Scale  Engineering  Development 

Government  Furnished  Equipment 

Global  Positioning  System 

Headquarters  Tactical  Air  Forces 

International  Civil  Aviation  Organization 

Identification 

Identification  Friend  or  Foe 
Inertial  Navigation  System 

Joint  Tactical  Information  Disbribution  System 
Liquid  Crystal  Display 
Lines  of  Code 

Low  Probability  of  Intercept 
Line  Replaceable  Unit 
Modular  Control  element 
Microwave  Landing  System 
Man-Machine  Interface 
Mobile  Microwave  Landing  System 
Message  Processing  Center 
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GLOSSARY  (cont.) 


NATO 

NMR 

NTDS 

OM 

OTS 

PME 

PPS 

QWROTES 

RAM 

RAPCON 

RFP 

ROE 

ROM 

RSU 

SEP 

SE/PM 

SRV 

T  ACC 

TACS 

TADIL 

TEMS 

TR 

TAOC 

TRV 

U/l 

VFR 

VLSI 

WOC 


North  Atlantic  Treaty  Organization 

New  Mobile  RAPCON 

Naval  Tactical  Data  System 

Operations  Module 

Off-the-shelf 

Prime  Mission  Equipment 

Precise  Positioning  Service 

Quick  Wartime  Restora'l  of  TRACALS  Equipment  and  Services 

Random-Access-Memory 

Radar  Approach  Control 

Request  for  Proposal 

Rules  of  Engagement 

Read-Only -Memory 

Remote  Surveillance  Unit 

Spherical  Error  Probability 

Systems  Engineer/Program  Management 

Surveillance  Resotral  Vehicle 

Tactical  Air  Control  Center 

Tactical  Air  Control  System 

Tactical  Digital  Information  Link 

Technical  Engineering  Management  Support 

Technical  Report 

Tactical  Air  Operations  Center 

Tower  Restoral  Vehicle 

Unidentified 

Visual  Flight  Rules 

Very  Large  Scale  Integrated 

Weapons  Operations  Center 
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